Bureau of Justice Assistance 


Office of Justice Programs m= U.S. Department of Justice 


Sta ndard Functional Specifications for | 
Law Enforcement Records 
Management systems 
(RMS) 


Developed by the 


Law Enforcement Information Technology 
Standards Council (LEITSC) 


La as 
Cy er 
Y STANDA\ 


Standard Functional Specifications for 


Lew Spyforeamansr eacores 


MAGHAGEMECHIESYSiCis: 
RIS) 


Developed by the 

Law Enforcement Information 
Technology Standards Council 
(LEITSC) 


‘O- sD 
Cry ... r 
Ys TAN DAY 


This document was prepared with the guidance, leadership, and funding of the Bureau of Justice Assistance, Office of Justice 
Programs, U.S. Department of Justice, in collaboration with the Law Enforcement Information Technology Standards Council. This 


project was supported by Grant No. 2003-MU-BX-0068, awarded by the Bureau of Justice Assistance. 


ACKHOWICGGeEMmenis 


LEITSC Governance 


Larry Boyd, Chairman 

Chief of Police 

Irving (TX) Police Department 

Police Executive Research Forum (PERF) 


Joe Akers 

LEITSC Staff Liaison 

National Organization of Black Law Enforcement 
Executives (NOBLE) 


Terry Chowanec 
LEITSC Staff Liaison 
PERF 


Ted Kamatchus, Vice Chair 
Sheriff 

Marshall County (IA) Sheriff's Office 
National Sheriffs’ Association (NSA) 


Mark Marshall 

Chief of Police 

Smithfield (VA) Police Department 

International Association of Chiefs of Police (IACP) 


Morris Roberson 
U.S. Postal Service (Retired) 
NOBLE 


Heather Ruzbasan 
LEITSC Project Manager 


G. Matthew Snyder 
LEITSC Staff Liaison 
IACP 


Fred Wilson 
LEITSC Staff Liaison 
NSA 


LEITSC Functional Standards Committee 


Joe Cassa 
Bureau Commander 
Wheat Ridge (CO) Police Department 


Mitchell Ray Davis, III 
Chief of Police 
Dixmoor (IL) Police Department 


Debbie Fox 
Information Technology Administrator 
Louisville (KY) Metro Police Department 


Michael Haslip 
Chief of Police 
City of Blaine (WA) Police Department 


Linda Hill 
Consultant 
IJIS Institute 


J. B. Hopkins 
Division Commander/Jail Administrator 
Story County (IA) Sheriff's Office 


Dina Jones 
CAD Manager 
Story County (IA) Sheriff's Office 


Bruce Kelling 
Bask Enterprises, LLC 
Managing Principal 


Daniel Murray 
IT Management Section Commander 
Arlington County (VA) Police Department 


EEE 
Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) iii 


Beverly Muse 
Technology Manager 
City of Chattanooga (TN) 


Morris Roberson 
Postal Inspector (Retired) 
U.S. Postal Service 


Jim Slater 
Chief Information Officer 
Massachusetts Executive Office of Public Safety 


Mark Steigemeier 
Vice President 
Motorola 


Darrell True 
IT Administrator 
Wrentham (MA) Police Department 


Gary Vest 
Chief of Police 
Powell (OH) Police Department 


Paul Wormeli 
Executive Director 
JIS Institute 


Advisors and Other Program Contacts 


William Cade, Jr. 

Director, 911 Services and Communications Operations 
Center 

Association of Public Safety Communications Officials 


Joe Estey 

Chief of Police 

Hartford (VT) Police Department 
Former LEITSC Governance Member 
IACP 


Joe Heaps 

Communications Technology Portfolio Manager 
National Institute of Justice 

Office of Justice Programs 

U.S. Department of Justice 


Dustin Koonce 

Policy Advisor 

Bureau of Justice Assistance 
Office of Justice Programs 
U.S. Department of Justice 


J. Patrick McCreary 
Associate Deputy Director 
Bureau of Justice Assistance 
Office of Justice Programs 
U.S. Department of Justice 


Harlin McEwen 
Chief of Police (Retired) 
Ithaca (NY) Police Department 


David Mulholland 
Lieutenant 

U.S. Park Police 
IACP 


Jennifer Zeunik 


Former LEITSC Project Manager (2002-2005) 
IACP 


Project Manager 


Heather Ruzbasan 

LEITSC 

International Association of Chiefs of Police 
515 North Washington Street 

Alexandria, VA 22314 

(703) 836-6767, ext. 275 
ruzbasan@theiacp.org 

www.leitsc.org 


Special Thanks to Our Partners 


www.ijis.org 


This document is the result of an extraordinary 


collaboration between many justice practitioners and 
industry experts. Thank you all for your commitment, time, 


energy, and patience. 


iv Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) 


IGDICTOMGOnICHIS 


ACKNOWIGUGGMGINS iii ceccccsssctececccscicccssnsssceccsnasccceceereacceceerasccceavensscceecenssscceces casccdeescasacenedendsecceces a scacasieasacetieerssecesaenssseesuezeate iii 
Table Of Conte int «cise csccccccectecesscctsccsscadiccsssecaceccecesscctsesaesadeccantencceccesscececcneassactetendvecedcnssenccedensesscececenenecceenesencceccesersccnteeeteadan V 
Executive Summary: Records Management SyStemm.........:ccccsssseeeccessseeeeeeseseeeeeenseeeeeeeeeaeeeeeesesaseeeeseeseseneeseseseneeeseeeesenees ix 
Business Function: General Requirement: icciccscicicccsssssoscesncctscstcenssvsnasnenccniessseaescsnnsccascnnensecisseenecastinnanstscesred caatvererenscats 1 
Business Function: Master Indice iii: iccsciiiicccscscscssccsceestcccseenes ceecetecs caceseearsseesieeesscaesenetssneasteecsnanceeesssassetceecsaanteteceaseceeees 3 
2.1 USE CASS: DIAQU AI sires sce vansc sd eae ecdane eels Seedente dente wane nbd ceeee daa dadbedaagea baad foun -daduntbakes fautbeeadi vaaue ia deeh eeetdnedveaoendap anes 3 
2.2 Use Case: Master Name INd@X sc... :iiiiecsiaacesieeeseateeeianti ile dears pdeceed ceeestelevacedaaernesdnede ea aed ecb duende 3 
2.3 Use Case: Master Vehicle ING@Xx .0........ccececcececcececeeeeeeeeeeeeeeeeseaeeceeaeeeseaaeeeaeeeecaaeeeeeeeecaeesseeeeeseaeeeseaeeeseeeeesiaeessiseeeesaeeseaes 5 
2.4:Use Case: Master Property Index :i:n4:.aiie te aaee nb nash ea iel O ai bite nadie he ade eniele dees 5 
2.5 Use Case: Master Location INdeX ...........cccccececceeeceeceeeeeeceaeeeeeaeecesaeeeesaaeceaeeeecaaeeseeeeecaeeeceeeeseeaeeeseaeeeseueeesseeeesiseeetsateseaes 5 
2.6 Use Case: Master Organization IN@X.............:ccccccccecencececeeeeceseeeeeaeeeseaaesaaeeeecaaesaaeeeeceaeeegeeeeceaeesseaeeeceaeeeseaaeeseeeeeseiaeeesaes 5 
Business Function: Calls for S@rviGe iiiscscccscccccsccsccsiecteceaciscestsnaccecstueevsiecteenestecestensdcaasteesscncaseestcteateesredsassieerseaaseeeseetaaenestsd 7 
3.1 Use Case Diagram ..........ccccccccecescececeeceeeeee ce eeeeceeaeesaaeeecaaaeetaaaeecaaaeeesaeeseaeeeseaaesaeeeeseaessqeneeecaeeeseaeeeseeeeeseaeeeseneesssaeessenees 8 
3.2 Use Case: Transfer CFS Data to RMS............:ccccccccccsceceeeeeeeaeeeeeeeeeceaaeeaeeecaaaeeseaaeesaaaeeseaaeesaaeeeeaaeeseeaeeesaaeseeaneesiaeeeennees 8 
Business Function: Incident, RE portinG jcccsiiicccsccccisccscceesscccssents cecsstecesasestnans cecsseees scaeectersseaastenessaccsseessassseedtcssaasteteesassceees 9 
4.1. .Use Case: Diagram sas iadtecesieaeiecteneasiaeerese tented nti teenieiael Andante raed ea death averted dae nieces tea ate a 9 
4.2 Use Case: Prepare Initial Incident Report ...............:cceccccecceeeeeeeeeeeeaeeeceeee eee eeeeeeaeeeeceeeeeeaaeeeeeeeceaaeeeseeeeeseaeseeeaeeeseieeeseeeeees 9 
4.3 Use Case: Create Supplemental Report ............ccccecccececceececececeeeeeceaeeeceeeeeceaeeeseaeesceaeeeecaaeeceeeessaeesseeeeesaeeeseeeeessueeessaeees 10 
4:4 Use Case: Report Review .2.ntniaauiidneecidn et ha ei eh eld ee ae elds ee ee lee 11 
Business Function: Investigative Case Manageme ntt............ccseeccsseseeeeeeseeseeeeeneeeneeeeeeeeeneeseeseseneeensneseenesesesseeesenneeneneanas 13 
5.1 Use Case Diagram ...........ccccccecescececeececeeeeeecaeeeeeaaeeeaaeeeceaaesaaeeecaaaeeesaaeeeeeaeeeseaaesgaaeeecceaesegeneeccaeseseeeesscueeeseaaeeenueeeessaeeeeaes 13 
5.2 Use Case: Assign Investigator. :s..2.:i.02 nite died hie cle eevee sateen at es ected ee ee Aad nee 13 
5.3 Use Case: Case MOnitoring............ccccccececceceeceeeceeeeceaeeceaeeecaaaececaeeecaaaeeeeeeeecaaeeeceeeeseaaeeeseaeeseaeeeseaeesecueeeeseaeseseeeeessaneneaes 14 
5.4'Use Case: Conduct Investigation .issi:..nusin ka ddd elem eihie Miadiva asain ateiedi evaded adenaetataedenelte 14 
5.5 Use Case: Charging ...........:cccccccccccecesceceeetecenceceeaeeeeeaaesaaaeeeceaaesaaaeeeecaaesaaeeescaaeeeaeeeeceaeeeeeaeeecceeeseaeeeseueeeseaeesseeeeessaeeseaes 14 
5.6 Use Case: Case Dispositiomiw.:. cc iannan adits nile een eee al ddan ele eae ede 15 
Business Function: Property and Evidence Management .........:ccccsssececcssssseeeeeesseeeeeeeseseneeeseseseneeseeseeeeeeseeaseneeseeseeeneees 17 
6.1) USE: Case: DiaQr eins: scccaeee le ctea see caestenedeetsaaaeie nate haves deven seat eis See daedadaasdeed cde aibedundeeddaate senna dandieyeeeedreetviedn eas 18 
6.2 Use Case: Collect Property and Evidence ............:.cccccccccceceeece cece eeceaee ences eeceaaesceeeecaaaesegeeeeceaaeseeeeeececeesseaeeseeereeeeaeene 18 
6.3 Use Case: Vehicle Impound ...........cecccceceeeeceeeceeeecaeeeeeeeeeceaeeeeeaeeesaaeeeeeaeeeceaeeeseaaeeceeeeesaeeseeeeeseaeseseeeeesoeeeseeeeseieeeesiaeees 18 
6.4 Use Case: Property and Evidence Storage. ..........::cccccceccceeceeeecececeeeeceaeeeeceeeeceaaeeeeeeecaaaeseceeeeseaeeeseeeeseceeeeseaeeseeieeeseiaeeee 19 
6.5 Use Case: Property and Evidence Disposition...............:ccccccccsececeeeeeeeeneeceeeeeeceaaeceeeeeecaaeeeeaeeeseeaeeesaaeesecaeeesiaeesesieeesiaeene 19 


EEE 
Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) Vv 


BUSINESS: UGE VW ANN AINE: cosets civic cate tidacdetecedacteauta taste vats tadac be nevnuasbeswna Saute cate betaelateaabies iar danbeasetetan lets dodaci niniabaetessteaenivins 21 


FA WS: Case; Dia Granny s saisicd cade on eh ceseeegenthanicceseatede oe davestevcgceas assets tas iicedscetiaet sees tases dentsaii-agees duns tiaapdedeaeadenees auateegeed aes 21 
7.2 Use Case: Receive and Process Warrant ..........2...::ccccccceceeeeceeeeeeeaeeeeeeeeeee cade aaa aaaanaeceeeeeeeeesgceaaaaeaaeeeeeeeeeeeeeeaeeessensaeeeees 21 
#3 Use Case: Verily Walt nt iis. caccecn cece cite secveccudvsaxcadednecctadadeecnedennsesddaasbaneeaqadhesesuaedenneseadaadeaneniia shes esstisatieenniade tae abe 21 
LA4-Use Case? WaltiAnt SCRVICE vr. caieesvesnas ccecedaceensacade uudseeeradas canvedcaeries chan ngtnccaiad eae sacs deewens couauete eadvaadeeeenddedeedes aed Abeueeaelea 22 
7.5 Use Case: Cancel Warrannt............:::ccccccccccceeeeeeeeeceneaecae cette eeeeete cea caaaaecaeeeeeeeeeeececeaeaaeaeeaeeeeeeeeeeeeececccasaeeseeeeeeeeseeeeeseesiaeeees 22 
BUSIMeSS PUuiaCticnra: - AGS Ussiciais ssaic cscs sda c aoe ase vas Sas Vado Shs dav bce ea a 23 
8. Use Case: Diagrams. iicceaiecccciesieetienceHitintdlavetsiadeavteeitaaebeetetdanes hada de etecaneteetdatteeashdaeteioiieasreded hast tieehaasteenialenenedd 23 
8.2 Use Case: Arrest SUDjOCE ccc cecgteceneeeetecceeeeeneneceneeennecneeeenaaneneeeenaetaeeeenteneneeenqaneuedectaceeeneenaneeeeseenaeeeeseeehiateetecnaneeenenent 23 
3:3: Use Case: Arrest Warrant SQrviCe viii icc ccseceensaveac eon ceehcadenceevesvunvcaee atten ceveicauseunevadede as dees sdvace vuasauiees caledetuesdedeensave deeandeaeia 24 
8:4 Use: Case® DUI AMeSt ncsscsasiecs.ccieclnce.nsesdacvess dectalecatedeeatcscnceecculects (éeeth caeehenana dues Gases er secnann lh dn tie ec daae4atecatsohensvaesaeeGuseateesdadesers 24 
Business FUNCHON: BOOKING iiss ssisccccssssscecccesvcccc cacsccctcccdssiedecdeassaccscatenaalbicds saaucecd vissaciscsisiscii cava ssoutieasrssauidebevseasteavasdontecas 25 
9:1 USe Case: Diagram ..iccccateeticcteidisinceseyetivadl eect Qutcdeneddbacatieh chagdaeiisuidee tei euiacastiiaieditats ictenennedaa devas eebadeneceanass 25 
9:2 Use Case? Process SUDJOCE ii.2...cc.cctteeeecaenesseecadecneeedishneneendaanndeedueeseentacdigeasessueaanueenedacsbebesnaadeeneeudi¢ageecesdaedesseensaeeereeens 25 
9:3' Use Case: Verily SUDJOCE ic cccicigeccceteeeiedtiede evisu tec vectad eet edch nee sven evice doy dias: « vinnecee evan ania vaste eee 26 
GA USE Cases REICASC: rs ccsccccacccc chez ance ect etecens seid sadeeyedsddauacus eh ssn ccsdsacendcnntesdudea'se'adesnetsuendeve: fadaccadetedashecstedgedsveuuieetastadeeeteaecces 26 
Business Function: Juvenile GComtact sississcscisss ci iicsicccsuss vasusaasivi ces ansvcessenscewaads dara v va susaaies vd os uaseotssundvrsvoauesvansdecesserentsaaaasesyes 27 
10:1 Use Case DiaQraimtiriiicsscivecisssdree iets ietaceccectesiacades eaeaadencnedecdennetnas bene cated ccna eddiinenaezeans aaa engl adnate 27 
10.2 Use Case: Juvenile Contact ........ 2... ccececccccecce eee ee erect eee ee acca eee eee ee eee e cea aaaaeceeeeeeeee ees ccaaaeaeeeeeeeeeeesesecccnccisaeeeeeeeeeeeeeeenee 27 
10.3 Use Case: Juvenile: Detention ois. sic iccescediecseeiavees sacs dadeceectebdagetes Yaa dayadentiaunds cava ie ane cuavaae Gia cuted da cdaeersaiaduaacentadearareidendeviedle 28 
10.4 Use Case: Juvenile Referral ...............c:cccccsccccceeeeeeeeeeececceeeeeeeeeeeeeeceeseaaaaaaeceeeeeeeee ees cccaaaeaeceeeeeeeeeseteceenccisaeeeeeeeeeeeeeeenee 28 
Business Function: Traffic Accident Reporting ............essecccseesseecesseeeeeeenseseneeseeseeneeesneeeeneesenseseneesusueeneeeseseeseeesenaeeneeeenas 29 
TWh Use: Gase Diagram ::siesecoiviccsterie ha theectanichecotealdiaiedeeiaandeccnaglacenienis bed ad eeedaivielionsieidnns hasdeenel cada eads 29 
11.2,Useé Case: Accident REPOminG :a.:..:.2..2.:cccecececcceaescsec tageewaecaeteeeeceedneesseenend ceva ended tttanenessttaaedeastseandeabdihaaenenediaaeteeiitens 29 
Business: PUunCtiOn:: Citation wziiaivaveditcidicisice bocce tetbalvass yeh oy ed di catavan dd Abaca acete cule ahaa dedet ac vansvadaiesatiea vrai el dat A endanieseas 31 
12:1 Use: Case: DiaQraini ni ivssecciiiecsdenveseagusbentescedesihashaades eesetd ch anetadbeereedaseueeede thee caetneeadeeauedd eee teed anes ead deed 31 
12.2 Use Case: ISSUC Citation .......... 2. cccecceccceecee cee ee eee ee tee eee eee aeee eee tence eta ceaaaaeaeceeeeeeeeeedeaaaeaanaeeeeeeeeeeesadceenaaeeeeeeeeeeeeeeeeieee 31 
Business Function: Field Contact inascisiinsiiiicn cian aie eee ae 33 
13:1 Use Case: DiaQranntis. icssiiiiieistticaddeceteasccceectesacadeeeeasaedencnsseguoneiaaedeenre sated ceeetdentea neta ated gl eanedneeesenceads 33 
13.2 Use Case: Document Field Contact .............cccccccceeeecececccee cee eeeeee eee ee eee caaeaaeceeeeeeeeeeeseacaaaaecaeeeeeeeeeeesesececacaeeaeeeeeseeeeeeeeseee 33 
Business: FUNCtION:: PAWN i issidccs iy svasevehectani beta cudecdsbvasasitatecsasits iegaled ied ty overetated daa tat anal ni idaceaveretabd iin talevceaiebdinvet beldaenies 35 
T4.1 Use: Case: DiaQrenni ic scsccccesvcuseciretsscuchivid ease tives sa cddetveseadelageadeedearitkaiesesantaded ved ceeee nena eatedihanestedeveseeeedheaaiennedesdhuieenedts 35 
14.2 Use Case: Receive and Process Pawn Data .............:::::eccccccceceeeeeeeeeeenecaeceeeeeeeeeeececeaeaaecaeeeeeeeeeeeeeeenaaaaesaeeeeeeeeeneeeeseae 35 
14.3 Use Case: Seize: Pawn Properly’ s:.cscstescesccecede ce beedwes iebedente seta dela cctddecane dtadedevsecined ens calaeeinvecieaedeveciiedevancadagenmcteienedss 35 
14.4 Use Case: Analysis of Pawn Datta... cece citer i enn tr nant e renee een nnae eee en ea aae ee eeeeaaeeeeeeeaaeeeeseeaeeeeseeeneeeeenenaaes 36 
14.5 Use Case: Regional and State Pawn Reporting. ............ cc ceccecceeenereeeeeene eee eeenaae eee eeeaeeeeeeeeaeeeeeeeaaeeeseeedeeeeseeiaeeesenenaees 36 
Business Function: Civil ProC@s Siicisic iiss setevctasescets tests nti lsiiiehs eee ee eta ese area nee 37 
19.1 USC: CaS6: DIAGRAM 2: c.c20 icc uses ence ceeneeccees lezen cevsaheeiece-naetenceeedaeecscevuhatecsscuaadedeceueadcensevadeedeceeugeebatsceueaeecseesuaadecensaeaeteeess 37 
15.2 Use’ Case? Serve Orders cocina aces eeciseiee sachs cee aadca tus uae eatende ta ce yeaa Porat beet aal basen Gaveseye ive waned ndegiaeaper tua andneds caeees ches raadaeetnoane 37 
15.3 Use Case: Seized Property «0.0... cere ri ern tr i nn ri nr inerrant ee enn nae eee ee eaaae eee eeeaaeeeeeeeeaaeeeeeeeaaeeeseeeneeeeeeenaaes 37 
15.4. Use. Case: Bin sccevsscsgceet sit eceeeesdewecseetdvhedestte nan destaedieeeeateddewecesdhi sha deael feed cecavecnabe da vicaseudvvi tastes wbideeevncdaieeetveuaade edad 38 
Business Function: Protection Orders and Restraints. ............2.ccs:cesseeeeeeceeeeeeeeeeeneeeeeeeeceeseeeeeeseeeeessseaneeseeseeeeeeseeseeneeeaees 39 
16.1 Use Case DIAQraim ......ccc.:.ceccecceceessccceccennceteceesnccanseeenacaenecesbbcedsersdnceaesensaaaaecedenanaacseeeahandeseseqasdedeeeadaaadesdesaedeseaaaandeceseds 39 
16.2 Use Case: Protection Order and Restraint RECOrING............:cceeeeeeeneeeeeeeecne test eee eee eeeaaaeeeeeeeieeeeseeeaeteeeeeiaeeeeeenaees 39 
Business Function: Permits and LIC@CNS6S o. icc: ccsicccccessssssnnesnecsccerecesscsneannecccareesscessennontcansenanevedssncnsennsancanaceascerdeesstinaanence 41 
TEA SC CASS: DIU ea xa siieees chs tans beeen eng sneer eteieasienvs evg heute eeu wanted odveaceed bs dael ones peanut ea daeeuebeephiebdsies panawene can dasseb reeesedee eke 41 
17.2-Use. Case: Application: ProceSSinG ais.<i03:sece<ceecsecsvacisadsiecntedanevae cabauadiuccudhhacceucedenduou st iavevacs che vaavdevssasedeaaeraeeteateciuearvacvee 41 
17.3: Use Case? Collection ices scicdscacceas ci dic geaseneesectasdesvdene cess. vae¥assevavssuss des scadadecethataadeasaasdacuevuacs tags aneestadsaanetacadeastéeetncceseseteatess 41 
17.4 Use Case: Background Investigation .0....... eee enn rr nner rennet rennet eee enna dete en eeaaeeeeeeeaaeeeeseeaeeeeseeeieeeeeeeiaaes 41 
17.5 Use Case: SUSPENSION-REVOCATION...........:.cccceceeeeeeeeececeeeeeeeeeeeeeee cece aaaeaaeceeeeeeeeeeescceaaaecaeeeeeeeeeeeeesecesacesaeeeseeeeeeeeeeseee 42 


TC CCC (EE Eee 
vi Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) 


Business Function: Equipment and Asset Manageme itt ...............::::2:eeeeeeceeeeeeeeeeeeeeeeeeeeeeeeeeeseseeesaseanenseeseeeeeeseeeeeeeseanes 43 


48.1 USE: CaSO: DIAGraIM:. se sices csc eschc ene cveideceecvnnectedensuacen dee -nadeeces covaeeetcadskeecedvashcenseckeadeeheanuacedhsencgastenssancnadeaeedaaadhdneeideasehes 43 
18.2 Use Case: Equipment RECOIDE +. iveriscencitensteradecashaeca ie cicives caceucepeeducludecsccnaeseaca ceuu seins ai @duaneegua cose rs aaaadinenaaeeqereesieeeuanmnendl 43 
18.3 Use Case: Equipment ISSUANCE ..............cccccccceceeceeeeeeceeeaaeeeeeeeeeeeee cece saaeaaeceeeeeeeeeeececccaaecaeeeeeeeeeeeeetecccacesaeeeeeeeeeeeteeseee 43 
18:4.Use Case: Equipment: Checkout « :iiiic. dssewscseidscedsacesadecececehenevae condvagvucetdhbteseveniealsovasbatevacsctdsaavaeeusatudesaceacenedvachidemies ackie 43 
18.5 Use Case: Equipment Check-in ............:ccccccccceceeceeeeeecenecaeeeeeeeeeeeee cece aaeaaeceeeeeeeeeeececeaaaecaeeeeeeeeeeeeesecccncesaeeeeeeeeeeeeeeseee 44 
18:6 Use Case: Physical Inventory/AUGit 2 c0:..cccceecectedeetccnescecdeensetensi ccnabedentctaeetesdvcsaedenscdaaeesesnciatuesstccaezgeencuseedeeencageesestceae 44 
18.7 Use Case: Equipment Maintenance: ...............cccccecceeeeeeeccee cee ce ee eee eee e ceca aeeaeeeeeeeeeeeeese ace aaaecaeeeeeeeeeeecetececncaesaeeeeeeeeeeeeeeeeee 44 
18.6 Use Case: Equipment DISPOSAl i visite. issaececeeedsnes dues ante deve genecas eonzaaudeetianeds cxeeiendaguavaleedecncha dees advasadadedienaeanvesaviadenaetvichs 44 
Business Function: Fleet Management .....:2:.:::::ccssseccccsesscccecsssssnceecessssccecesessencecseesenceecesstectecesesseceeedsesenceesasssaneecaestaceeesds 45 
49-1 Use: Case. DIAGranm: 2. 2.cteFsccecie sc deabecsecevacet ace tiaeesdiek ushtecseevandernscadaabescckcush densevudaceensenvas Supe cuaetensCaudadetecrvsasadtieveadedeneerds 45 
19.2.Use Case: Fleet RECCIDE ei isteseie iacevaevaaitededonadeaas odes avuaca ces caeadeeeveduaarecenaainadives cesedetaueneuacaves laetber es avageinen cae dianers eae ae 45 
19:3 Use Case: Fleét ISSUANCE: .1..2..2. cif ceesceeeeectecyeedecuee theeaeescqebeaudbetghesesseccnheensaecnabeensceedhecesarenandeesarsqndenvaccedeeneaateagaseeweeeaa 45 
19:4 Use. Case: Fuel LOG eis. ic: ccecicieecteseenceated sunedectievaadiecten cnadoceseddhnechvabevaescavadeisdecheedeaweusuheaneeeshceededsoedadeeeseedsneeneeeddbbieessteeds 45 
19.5 Use Case: Fleet Maintenance .00...... ecient i rn rin i i ne nee nn ae tee ened ae ee eneeaae eee ee eaaaeeeeeeeaeeeeseeenaeeeeeennaaes 46 
19.6 Use Case: Damage Re pOrtinGe aaiicccccctecceccecetedeadadews citvacesdeieiegessaeceadedew cissedevdicasddeestcdaaeneevicdaeedevinesaedesuiagiadieveecigeaeestiaa 46 
19.7 Use Case: Fleet Disposal ................ccecccecccccccecee eect tet ee eee ee aeee eee cence es cage aaaanaeceeeeeeeeeegdeaaaaaaanaeeeeeeeeeeesaeececaeaeeeeeeeeeeeeeteeieees 46 
Business Function: Personnel sis cccctesicceszcesavsscicescavsvicctesvesasetad seca civcdassivucs debs scues fades sosevabesvivacebets swuni ia leasievebevdecneedaieanaveies 47 
20.1 Use Case DiaGraint.iciessceccagececveaatesteesadleesdeciaukiad esd guuel dees Ractevved ebb es veausiees ev eiadiee eeveatagiecveaunineeataiee animes rian vd 47 
20.2 Use Case: Operational Management ............cccecceeeteeeeee eee eeeeee eee eeeeeeeeeeteeeeeeeeeeaeeeeeeseeeaaeeeeseeeaeeeeseseeeeeeseeaaeeeseneaeeess 47 
20.3 Use'Caseé: Personnel Informations ..:::.:2::.cciece testes hicdereteaecnaniteelene in a ilineinien eenediieenalinsdeinnaiehdesita 47 
20.4 Use Case: Scheduling and ASSIGNMENT ........... eee eeceeeeeeeeee eee eeee cette teeeeee eee taeeeeee te eeaeeeeeseneaaeeeeceeeaeeeeseeeeeeeeeseeaaeeeseneaeeees 48 
20:5 Use: Case: EXCOptlom vecsicseite ues ccereataecaee ta exdsueeaseusiedavs sued ene tuadv aca vaas eulcarecaetdeb urs iunevansdanecucacaaa casdaeesaueavaccaauseas ers Aved eave vie 48 
20.6.US6:CaSe? DULY ROSTCR 2 ei sis ee icc eckee cies ecan eu vane cee cued occ cevndeecadenudaadeceesnedecceeauseecteukendeceeeasbanascaumdedecessadeatecendaeednaserea 48 
20.7 Use Case: Training and Genitications:ci.icceccicieeacnceen eiichieaiened eaten anadeenieisnniedeeaataadenichidenndieedide 48 
Business Function: Internal Attait's 22s: icccccccsscccccesssscccccsessecseeescsssceccesssssceessssseceeeeessseieersevsscerssssssceessavssneeseastsenceessvieeceests 51 
21.7 US6' Case: DIA Qrannn sis teaaeescsccecesencecacecee ceeesdetehesnattten ee sagdene ceeeseadnane tnatdasneaeaddeneeeedagd tea ne dettbenedaitsheseeedaaabeenetaatne necnaieeereenee 51 
21.2 Use Case: Conduct JA INVEST Qatonic..ici..ccccceccceecectectacceneeseaacenreedaneeceebeaaaueenenedaceanceesagcnsnebeanaaeeeasvaadeaneasaaegesccnedasneeeaerds 51 
Business Function: Analytical Support (Crime AnalySis) ..........:ccccssseeeeeesssseeeeeeseeeeeeeeseseeeeeseseseeeeeeeseseeeeseeeseneeseeneeenenes 53 
22.1 USE: CaSO DIAGrAMNs cccecccs.cescenauies Pouce ascascea tal sdee ded ce neteayssuiedanteadgeia «sev keh dne¢vsadedacecasiant¥essstabtea ss tended er saeed eeneeee ates 54 
22.2 Use Case: Tactical AnalySIs:..:2::i..ccsciiiicceiiicceciivieacceriecccstnideceeanivie iene ivewessndiiescseanenaaaeanieeaaasesnnaaiceaiivdaecsiveanas 54 
22.3 Use Case: Strategic AnalySis .0........ccccceeccececeee scence eee eeceeee eee eeeeeeeeteaeeeeeeseneaeeeeeseeeeeeseeeeaeeeeseeeaaeesseeeeaeeeeseeaaeeeeeseaeeegs 54 
22:4 Use: Case: Forecasting Analy Si8 viicsiscctisccesccievaeiccct sate canivdtauee neiecesde cnet dedeeddeaetievbataetecddaede dd dante eeaaed 54 
22.5 Use Case: Administrative ANalySis 0.0.0.2... cc ccceeeceeceeeeeenneee eee eeneeeeeeeeeeeeeeeceeeeeeeseeeeaeeeeseneaaeeeeceeeaeeesseeeeaeeeeseeaeeesenenaeeess 54 
BUSINESS FUNCTION: FRMIS RE DONES sii iis sssasisascisss 255 2icieass vivesucae ia Hi cc auisvv os danas vaca aiid va sis atev vd Su tet aes eas web suaW Redenannenssaaaleesves 57 
23:1, Use Case DiaQrainte:iiccscsitesiehanieds agatenecd dlacaderesanages ceva jue dennvaua ce cove adaagy.eevauadgs cnrsatagacon sadaeieessdliddoeesagiagieenaiguaieresade 57 
23.2 Use Case: Aggregate Reporting..........ccccccceccceneeeeeenneneeeeeeneeeeeetecneeeeeeteeeeeeeeseeeeeeeseeeaaeeeeceeeaeeeeseeeeeeeeseeaaeeeseenaeeess 57 
23.3 Use Case: Standardized REPOming 2. .eiccieeuieiscesceetieeadecveteeaeeeetaceieerideaadeneed adeetieesegenen ett dasieetageadeaneastieeeeeadeeteneees 57 
23.4 Use Case: Ad Hoc Reporting.........cececcececeecceeeeeeennee eee eecneeeeeeeeneeeeeeseceeaeeeeceeeaeeeeeceeaeeeesegeeeeeeeseeeaaeeeseseeaeeeeseesaeeeesseaeeees 57 
Business Function: RMS System Administration ...........:cccccessseeceeseeeeeeeeseeeeeeeeeseeeeeeeneeeeneeseesesseeesnssesneeesesessneeseeneeneeeenss 59 
24.1, Use Case: DiagQraimt .:.iicccisitvalernedeiegs chad adeeb ens daceederevauetis ereagdees ansvateliadnvsa legis eetantedscvagathedoesaluaaieehauachseagueaetonacauaiernadi 59 
242 SC CASE? SOCUIMY © siee esti ceklencceeeeented cntxant ented duadenne o0ghou Dee en Maneiids ivan deed bs bhde cee e saeaeen devo dae ah pa badee nes Saeabat cen diesdtbeaeeadeene ore 59 
24.3 Use: Case: RMS: Table: MaintemanCe ss. ..ic.ci--sciescceeceetstadecncedeeueeeeeesacececiedbacseseeedeeiees eesaseeneid baud eaadaiens esdkeseaueteedaad 59 
24.4 Use Case: Data Management ..........ccccceceeccceeeeeeeeee eee eeneeee eee eeeeee eet eeeeeeeseeeeeeceeaeeeeseeeaaeeeeteeeaeeeeseseeaeeeeseeiaaeeesenenaeeess 60 
24:5 Use Case: Geofile: Maintenances. iist..eicicsssareiactedeetaasceandeaeigzencttgucledertviaeeden ees cadiecnd a deanee siete se aanengeeeadicedtngneaeidias 61 
24.6 Use Case: RMS Configuration ...........cccecccccceeeeeeeeee eee eeeneee eee eeneeeeeeseaeeeeeeceneeeeeeeceeeeeeeseeeeaeeeeceeeaaeesseeeeaeeeeseenaeeeessenaeees 61 
Business Function: RMS Interfaces iis csticccisccscccctaccscicctessseuattedec cosicebac ctstvedase scat cs les sauivebavsasucebaevscatetaseceaistassviacavedeveisieeess 63 
20:1 Use Case DiaGraint tives scissncdeevsatuesdevsatecdieviaukidd ects ganee cose decd veveaubieesveaugiees wenedlie eeventieayevsauuihesvaauaiea ranmazeraiiadeavaadl 63 
25.2 Use Case: CAD Interfaces .......ecccceeeeeeeee eee eeneee eee eenneee seer aeeee eet aeeeeeeeneeeeeeesaeaeeeesegeeaeeeeseeeaaeeesegeaeeeeseenaeeeeseeaeeess 63 
29.3 Use Case: Local/Regional Interfaces «....ic22.ccicsetoes eiedereeetcgeets eden ecdbnee ed badeeetsicaeneesnedadeeaeaaalitadedeseniagtenedeeaads 63 
25.4 Use Case: State/Federal Interfaces 20.0.2... cceecceeceeee cence eee eeee eee e eee eee eee ceeeeeeeeeaaeeeeeseeeaeeeeeceeeaeeeeseceeeeeeeteeaaeeeseeeaeeees 63 
GONCIUS TON sais ss sates cases adibdcaied a da icin id Sait echinacea beaded ce mw baa Sa hs aa adeeb daa hie eae tae dae a 65 


Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) vii 


EXEGUNVE SUM GIy: 


RECOLOSWVIGHUGEMeCH In ySICN) 


History 


The Law Enforcement Information Technology Standards 
Council (LEITSC) was created in 2002 with funding (Grant 
Number 2002-LD-BX-0002) from the U.S. Department 

of Justice, Bureau of Justice Assistance, and continued 

in 2003 with funding (Grant Number 2003-MU-BX-0068) 
through a collaborative effort between the Bureau of 
Justice Assistance and the National Institute of Justice. 
LEITSC is currently funded under the Bureau of Justice 
Assistance (Grant Number 2003-MU-BX-0068) and 
continues to work in cooperation with the National Institute 
of Justice. LEITSC brings together representatives from 
the International Association of Chiefs of Police (IACP), 
National Sheriffs’ Association (NSA), National Organization 
of Black Law Enforcement Executives (NOBLE), and 
Police Executive Research Forum (PERF) to address law 
enforcement information technology standards issues. 


The mission of the group is to foster the growth of 
strategic planning and implementation of integrated justice 
systems through the development and implementation 

of information technology standards. With guidance and 
leadership from BJA, LEITSC involves law enforcement 
partners to speak with a clear and consistent voice in 
shaping the course of crucial developments in information 
sharing. 


The national initiatives include the Law Enforcement 
Information Sharing Program (LEISP), Law Enforcement 
National Data Exchange (N-DEx), and Law Enforcement 
Regional Data Exchange (R-DEx). 


As law enforcement agencies move toward the 
procurement of computer aided dispatch (CAD) and law 
enforcement Records Management Systems (RMS), it 

is vital to recognize and consider the Law Enforcement 
Information Sharing Program (LEISP) developed by the 
U.S. Department of Justice (DOJ). The LEISP is designed 


to promote information sharing among all levels of the law 
enforcement community and to guide the investment of 
resources in information systems that will further this goal. 
The goals of LEISP are supported through the proliferation 
of the Global Justice Information Sharing Initiative (Global) 
Extensible Markup Language (XML) Data Model (Global 
JXDM). For additional information on the Global JXDM, 
visit www.it.ojo.gov. The Global JXDM is an XML standard 
designed specifically for justice information exchanges. 

It provides law enforcement, public safety agencies, 
prosecutors, public defenders, and the judicial branch 

with a tool to effectively share data and information in a 
timely manner. There are several ongoing DOJ initiatives 
incorporated into the LEISP. 


One program currently being developed jointly between 
the Federal Bureau of Investigation (FBI) and state and 
local law enforcement is the Law Enforcement National 
Data Exchange (N-DEx)' System. A second program—the 
Law Enforcement Regional Data Exchange (R-DEx)? 
System—has been developed and implemented by the 
FBI. Both programs are new law enforcement information 
sharing systems based upon the above critical standards. 


1 The N-DEx Program is an incident- and case-based information 
sharing system (e.g., RMS) for local, state, tribal, and federal law 
enforcement agencies that securely collects and processes crime data 

in support of the investigative and analytical process and will provide 

law enforcement agencies with strategic and tactical capabilities that do 
not currently exist on a national scale. An N-DEx concept of operations 
(ConOps) document is being finalized to aid in the design of the N-DEx 
system and to ensure that stakeholders understand and share the N-DEx 
vision. 


2 The R-DEx Project seeks to securely share sensitive but 
unclassified crime information between federal agencies, while allowing 
for connection with several existing regionally based local and state 
information sharing systems to impede criminal and terrorist activities. 
R-DEx is now operational in several metropolitan areas. 
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Purpose 


In 2003, LEITSC identified the need for a national standard 
for Records Management Systems (RMS) functional 
specifications with the following goals: 


® Provide a starting point for law enforcement agencies 
to use when developing RMS requests for proposals 
(RFP). 

® Streamline the process and lower the cost of 
implementing and maintaining an RMS. 


® Promote information sharing. 


With these goals in mind, the LEITSC Functional 
Standards Committee, composed of law enforcement 
practitioners and industry experts from around the country, 
was appointed to develop the Standard Functional 
Specifications for Law Enforcement Records Management 
Systems. The baseline document was developed 

from common elements found in the RFPs, technical 
documentation, and other RMS-related research. The 
document was then validated by the LEITSC Functional 
Standards Committee using a computerized modeling tool. 
Once developed and validated, the specifications were 
vetted through the law enforcement community via each 
of the participating associations, as well as through other 
stakeholder communities, in an effort to gain input from a 
number of different perspectives. 


Document Scope 


This document presents standard functional specifications 
for law enforcement RMS. The specifications found 

in this document are intended to be generic in nature 
rather than favoring one particular system or approach 
over another. They are at the functional level in that they 
define what is to be accomplished versus how it should 
be accomplished. These specifications were developed to 
depict the minimal amount of functionality that a new law 
enforcement RMS should contain. They are not intended 
simply to be substituted for an RFP but should be tailored 
to fit the specific needs of each agency or group of 
agencies looking to purchase or upgrade an RMS. These 
specifications should be used as a starting point to build 
a fully functional RMS, based on agency needs and open 
standards, to efficiently interface and share information 
with other systems both internally and externally. 


It is expected that the process of defining detailed 
information exchanges in RMS will be addressed in future 
phases of this project. In addition, these specifications 
are intended to be used in conjunction with technical 
standards such as the U.S. Department of Justice’s (DOJ) 
Global Justice Extensible Markup Language (XML) Data 
Model (Global JXDM) to streamline the process of sharing 
information. 


It is intended that these standards will be updated and 
augmented on a regular basis. 


Introduction 


RMS is an agency-wide system that provides for the 
storage, retrieval, retention, manipulation, archiving, 
and viewing of information, records, documents, or files 
pertaining to law enforcement operations. 


RMS covers the entire life span of records develooment— 
from the initial generation to its completion. An effective 
RMS allows single entry of data, while supporting multiple 
reporting mechanisms. 


For the purposes of this document, RMS is limited to 
records directly related to law enforcement operations. 
Such records include incident and accident reports, 
arrests, citations, warrants, case management, field 
contacts, and other operations-oriented records. RMS 
does not address the general business functions of a law 
enforcement agency, such as budget, finance, payroll, 
purchasing, and human resources functions. However, 
because of operational needs, such as the maintenance 
of a duty roster, law enforcement personnel records and 
vehicle fleet maintenance records are included within an 
RMS. 


This document addresses the following business functions: 


Calls for service 

Incident reporting 

Investigative case management 
Traffic accident reporting 
Citations 

Field contact 

Pawns 

Civil process 

Orders and restraints 

Permits and licenses 
Equipment and asset management 
Fleet management 

Personnel 

Internal affairs 


Analytical support (crime analysis) 
In addition, the following support functions are addressed: 


Master indices 
Interfaces 
RMS administration 


RMS reports (general) 
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The following are general requirements of RMS: 


® Single entry (i.e., no duplicate data entry) 


® RMS should automatically submit data to external 
sources as defined by the agency 


© Maximum use of code tables 
© Ability to enter and query narrative(s)/text fields 


® Spell check and formatting capability on narrative(s)/ 
text fields 


® Ability to access multiple systems from a single RMS 
workstation 


® Single database (i.e., virtual or physical) 


® Validation on data entry (i.e., logical edits, edit checks 
for all fields) 


Some functional specifications need to be addressed at 
the agency level, such as the identification of specific 
external agency interfaces. These unique functions are 
addressed within each applicable business function. For all 
exchanges generated by RMS, conformance with DOJ’s 
Global JXDM is required. 


Internal and External Databases: 


An agency’s RMS should provide the capabilities for 
users to generate inquiries to internal and external data 
sources—such as state Department of Motor Vehicles 
and criminal history files, as well as the National Crime 
Information Center (NCIC)—from within each module* 
where such inquiries make sense. 


3 A module is an independent portion of an RMS software application 
which provides specific functionality, e.g., Arrest and Booking. Each 
module performs those procedures related to a specific process within a 
software package. Modules are normally separately compiled and linked 
together to build a software system. Single modules within the application 
can normally be modified without requiring change to other modules, 

so long as requisite inputs and outputs of the modified module are 
maintained. 


In addition, RMS should provide the user with the ability to 
reuse and/or import data returned from external sources to 
eliminate redundant data entry. 


RMS also should provide the capability to electronically 
forward RMS data to external data sources, either 
automatically or upon the user’s request (i.e., based on 
agency rules embedded within RMS). 


The above capabilities should be based on existing and 
emerging criminal justice standards, including DOU’s 
Global JXDM; the National Information Exchange 

Model (NIEM); and the National Institute of Science and 
Technology (NIST), including the Electronic Fingerprint 
Transmission Specification (EFTS) and Facial Recognition 
Collection standards. 
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An agency’s RMS should have basic master indices 

that correlate and aggregate information in the following 
areas: people, locations, property, conveyances (e.g., 
vehicles), and organizations (including businesses and 
gangs). Master indices eliminate redundant data entry by 
allowing the reuse of previously stored information and the 
automatic update of the master indices upon the entry of 
report information. 


Master indices information can be captured in a variety 
of ways, including during the input of information from 
incident, traffic accident, and vehicle reports and citation, 
booking, arrest, juvenile, fingerprint, and mug shot 
subsystems. Prior to accepting an entry, RMS should 
automatically give the user the option of determining 
whether there is a match based on existing data. 


The system should support the validation and linking of 
addresses, commonplace names, and street intersections. 


Linkages among any information contained in the master 
indices (e.g., people to places or person to person) must 
be included in RMS. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 

® Query and retrieval by name, vehicle, location, 
organization, and/or property to produce a 
comprehensive response displaying all related records 
in the system 


Standard External Data Exchange: 


© The master indices serve as an internal or external 
portal for information sharing 


® Mobile computing system 


® State databases 
e NCIC 


Standard Internal Data Exchange: 
© Existing RMS data 


2.1 Use Case Diagram’ (see page 4) 


2.2 Use Case: Master Name Index 


The RMS Master Name Index (MNI) function links an 
individual master name record to every event (e.g., 
incident report, arrest report, field interview, accident 
report, and license and permits) in which the individual 
was involved or associated. Every person identified within 
these events is given a master name record. Should that 
person become involved in another event, the single 
master name record is linked to all of the other events so 
that by querying that one name, the system can produce a 
synopsis of all the involvements associated with that one 
person. It also facilitates the linking of additional names to 
an individual master name record (i.e., alias information 
and relationship data). In querying an individual MNI 
record, the user also would be able to view all related 
records, as well as those associated with that individual. 


When a record or report is added to RMS and a person is 
linked (i.e., indexed) to that event, the system should 


4 URL Integration collaborated with LEITSC to assist in 

the development of the functional standards. URL Integration 

used an alternative method to requirements analysis with their 
RequirementsModeler software. RequirementsModeler is based on 
Uniform Modeling Language (UML), which is the defacto standard 

for documenting functional requirements. UML was created by the 
Object Management Group (OMG) in 1997 as a standard for visual 
object-oriented modeling. RequirementsModeler, consistent with UML 
principles, automatically generates diagrams and process flow (Use 
Case and Activity diagrams). URL Integration’s Use Case and Activity 
diagrams were reproduced for use in this report. 
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Figure 2.1 
Use Case 
Diagram— 
Master 
Indices 


perform a very important matching function using a rule- 
based process defined by the agency. The purpose of 
this matching function is to either automatically link an 
existing MNI record or to present the user with a list of 
possible matches to the name so that the user can make 
the matching decision. RMS should provide a matching 
algorithm that will provide the ability to search the name 
file by a variety of criteria, such as sound-alike searching; 
phonetic replacement; diminutive first names (e.g., James/ 
Jim/Jimmy, Elizabeth/Beth/Betty, and Jack/John); and 
other static demographic information, such as age, sex, 
and race. 


Once a list of possible matches is provided, the user can 
decide whether the information should be linked to an 
existing master name record or whether a new master 
name entry should be added. This step is very important 
in maintaining the quality and integrity of the master name 
file in the system. In addition to names, the MNI should, at 
a minimum, capture and maintain information on: 


® Physical characteristics (e.g., current and past 
descriptors) 


® Race and ethnicity 
® Location history (e.g., current and past residences) 
© Employer information 


Master 
Jehicle Ind 


Master — 
roperty In 


Master 
ocation Ind 


Master 
Organizati 
Index 


Telephone numbers 

Known associates 

Alias names/monikers 

Available mug shot(s) and photographs 
Scars, marks, and tattoos 


Modus operandi (i.e., unique method of operation for a 
specific type of crime) 


® Identification (e.g., social security, driver’s license, and 
local and county identification) 


® NCIC fingerprint classification 


Over time, and depending on the circumstances, this 
information may change, and new information will be made 
available. Additional information can be added, but older 
information should be maintained and viewable. 


The RMS MNI should also provide maintenance functions 
that will permit a record or report to be unlinked from one 
MNI and relinked to another. Since it is not always possible 
to ensure that the correct MNI record is linked to an event 
record, it must be possible to correct it. Functions also 
should be provided that will allow two or more MNI records 
to be merged into one record. 
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2.3 Use Case: Master Vehicle Index 


Like individuals, vehicles often are directly or indirectly 
involved in events. When a vehicle is linked to an incident 
in RMS, it should be added to the vehicle record in the 
Master Vehicle Index (MVI), which provides an agency with 
a detailed, searchable store of information about vehicles. 


RMS should provide the capability to search on: 


Vehicle Identification Number (VIN) 
License plate number 

License plate state 

License plate year 

Registered owner 


Description (e.g.. make, model, year, color, style, and 
attributes) 


When an inquiry is made on a vehicle, the system should 
return a list of all events in which the vehicle was involved. 


In addition, RMS may require MVI to have external 
interfaces. 


2.4 Use Case: Master Property Index 


The Master Property Index (MPI) is the central access 
point that links all property records entered into RMS. 
Each record is catalogued by using unique property 
characteristics, such as make, model, brand, description, 
distinguishing characteristics, and serial number. Industry 
property coding standards, such as NCIC property codes, 
should be used during the entry of property records into 
RMS. 


In addition, any property records entered throughout RMS 
should automatically cross-reference MPI to find potential 
matches based on the unique property characteristics 
outlined above. 


2.5 Use Case: Master Location Index 


The Master Location Index (MLI) provides a means to 
aggregate information throughout RMS based on a specific 
address, a range of addresses, an area (i.e., as defined 

in the agency geofile), and/or locations based on X/Y/Z 
coordinates. A geofile is the location information base 

file for emergency 911 computer aided dispatch (CAD) 
systems. It also provides a facility to store information 
about a specific location that may not be stored elsewhere 
in RMS. MLI should store or provide access to additional 
premise information, such as occupancy, elevation (e.g., 
floor), and premise type (e.g., residence versus business). 


An assumption is made that all location information 
being processed in RMS is subject to stringent formatting 
rules. In addition, if the address is within the boundaries 
of the agency geofile, the actual location is validated. 
Typically, during the geovalidation process, key 
identification information, such as X/Y/Z coordinates and 
agency-defined reporting areas, is added to the location 
information. 


The geovalidation process should allow an address to 
be accepted, even if it does not appear in the geofile. 
Unverified addresses should be flagged for possible 
review. Optionally, all addresses or only addresses within 
the jurisdiction are available in MLI. 


2.6 Use Case: Master Organization 
Index 


Many events also involve an organization, such as a gang, 
business, school, or shopping center. Information about 
these groups entered into RMS should be contained in a 
Master Organization Index (MOI). MOI provides an agency 
with a detailed, searchable store of information about 
organizations. An agency should be able to search on a 
variety of data elements and obtain a listing of all records 
associated with that organization. Organizations may 
change location and name, but these changes should be 
tracked in RMS. In addition, MOI also should permit the 
linking of aliases to organizations (e.g., M&M Associates, 
doing business as Joe’s Pawn Shop). 


a 
Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) 5 


Calls for Service 


All calls for service (CFS) are recorded in a structured 
records environment, providing the ability to run reports on 
these data, while also maintaining a historical record on all 
calls. The data are either segmented or identifiable by the 
agency. 


Typically, data in this module cannot be modified after 
the call is closed because they serve as a formal audit 
trail of the information that started the law enforcement 
activity. If RMS is not integrated with a CAD system, this 
function must be able to serve as the initial point of data 
entry for a CFS. The basic call data (e.g. initial call time, 
units dispatched, and call disposition) can be available 
to facilitate the creation of an incident report. The data 
imported into the incident report can be modified, whether 
or not the call has been closed, to reflect the latest 
information known regarding the incident. Basic call data 
may be transferred at the time an incident number is 
assigned or at the initial closing of the call, depending on 
specified call types. 


In the event that CFS data are transferred from CAD to 
RMS, RMS should receive the call number and associated 
incident number from the CAD system. If the call does not 
originate from a CAD system, this CFS module should 

be capable of generating or allowing manual entry of 

a sequential event number and an associated incident 
number to link CFS and incident records. 


If the department is dispatched by a CAD system, an 
interface to the CAD system will be required to transfer the 
CFS data to RMS. The CAD workload® reports also should 
be available from the calls for service module. 


5 Workload is the metric or metrics which accurately describe the 
amount of work performed by or within a process in a specific period 
of time. For example, the Calls for Service (CFS) module contains 
information about the number of calls received and the length of time 
needed to process those calls. The data on time and number of calls 
describes workload. A workload report in an RMS is a compilation 
of data that provides a user with statistics pertinent to the functions 
performed by or recorded within a module. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


rene Outputs: 


Daily log showing all calls received for the prior 24 
hours from prior printing of the daily log 


® Activity analysis by specified geographical area and 
time period 


® CFS summary, by specified geographical area and 
time period 


® Activity analysis by day of week 
® Activity analysis by hour of day 
© Activity analysis by day and hour 
fe) 


Response time analysis by specified geographical 
area and time period (e.g., receipt of call, dispatch 
time, on-scene time, and time call cleared) 


Response time analysis by call type 
Time consumed by call type by hour of day 


@ 

@ 

©® Workload activity by resource assigned 
® Workload activity by group assigned 

@ 


Time consumed by day of the week and hour of the 
day 


® Time consumed by specified geographical area and by 
time period 


® Calls that should result in the creation of an incident 
report 


Standard External Data Exchanges: 
® CAD 


Standard Internal Data Exchanges: 
e MN 


® Incident reporting 
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Figure 3.1 
Use Case 
Diagram— 
Calls for 
Service 
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If CFS information is retransferred from CAD, the most 
current data will replace the information previously 
transmitted. 


3.1 Use Case Diagram 


3.2 Use Case: Transfer CFS Data to RMS 


The call data are transferred to RMS when units are 
initially dispatched after an incident number is assigned or 
when the call is closed in CAD. 
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Incident reporting is the function of capturing, processing, 
and storing detailed information on all law enforcement- 
related events handled by the department, including both 
criminal and noncriminal events. The incident reporting 
function collects sufficient information to satisfy the 
National Incident-Based Reporting System (NIBRS) or the 
Uniform Crime Reports (UCR). Incidents often are initially 
documented as CFS in a CAD system. The CFS record in 
RMS should be linked to the incident and should be easily 
accessible from the incident report. 


Certain types of incident reports must be available to 

the public. Witness information, as well as the names of 
juveniles who are subjects or victims, may need to be 
redacted for public consumption. RMS must be able to 
recognize the age of the majority in the jurisdiction by the 
date-of-birth information entered into the system that is 
available to the public. The system should support the 
redaction prior to printing a public copy or making the 
report available online to the public. 


The data captured in this module must support the 
preparation and submission of all required federal crime 
reporting and provide the capability to print a copy of 
both the completed department's incident report and the 
redacted incident report. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 
©  Allsummary UCR reports and NIBRS reports 


© Total incident reports based on period of time, area or 
beat, and incident type 


Location code (e.g., geocode) 
Initial call type 
Offense type 


Summary of incidents by a responsible officer 


Standard External Data Exchanges: 
Federal databases to support electronic submissions 


State submission following NCIC standards 
Prosecutor 

Courts 

Jail Management System (JMS) 


Regional Information Sharing Systems (i.e., standards- 
based, such as Global JXDM, NCIC) 


Standard Internal Data Exchanges: 
® Mobile reporting system 


® Investigative case management 
© Property and evidence 


4.1 Use Case Diagram (see page 10) 


4.2 Use Case: Prepare Initial Incident 
Report 


The incident report is prepared as soon as it is practical 

to do so following the incident and, depending on 
department procedure, may be updated throughout the 
initial investigation. Multiple officers may provide input 
once a single incident report is created and an incident 
number assigned. A primary officer will be assigned 

with overall responsibility for completing the report. This 
primary responsibility may shift to other officers during the 
life of the report. The incident report must contain sufficient 
information to comply with national reporting requirements. 


Typically, an incident report contains factual information 
pertaining to the incident, including offense information, 
suspect information, and case status, as well as 
information pertaining to perpetrators, witnesses, victims, 
and complainants. Reporting requirements typically 
mandate the collection of certain elements of information. 
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In addition, incident reports have free-text fields, which 
allow the collection of an unlimited amount of narrative 
information. The system should provide the capability to 
search the narratives for a specific word or phase. 


Once completed, officers submit the incident report to their 
supervisor for review. 


4.3 Use Case: Create Supplemental 
Report 

A supplemental report is used to add new information to 
the case after the initial incident report has been submitted 
and approved. The creation of a supplemental report 

may result from information gained during additional 
investigation and also may result in updating the status of 
the investigation, possibly bringing it to closure. 


Figure 4.1 Use 
Case Diagram— 
Incident 
Reporting 


Investigators are typically the individuals within the law 
enforcement agency responsible for follow-up investigation 
and for creating supplemental reports. To that end, they 
must be able to query and retrieve the initial incident report 
and use it as a baseline document for the supplemental 
report. They also must be able to electronically submit the 
report to a supervisor for review and dissemination. 


Multiple officers must be able to simultaneously create and 
add supplemental reports regarding the same event. 


All supplemental reports are linked to the original incident 
report. The agency should be able to link all of the 
associated reports with a common report number. This 
may be done using the original incident report number, 
possibly with a suffix indicating supplementals or a case 
number. 
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4.4 Use Case: Report Review 


The incident report must be able to be locked from further 
edits at a point determined by the agency. This does not 
preclude the viewing of the document by those with access 
permissions, but the ability to block access should be a 
capability of the system. 


Supervisors review incident reports and supplemental 
reports for accuracy and quality prior to their permanent, 
noneditable storage in the local RMS database and/ 

or their distribution to the agency records bureau; to 
other agencies; and to local, state and federal criminal 
information repositories. 


RMS must allow supervisors to receive, review, and 
approve incident reports online and to electronically 
respond to submitting officers and investigators regarding 
report quality and accuracy issues. The department’s 
Standard Operating Procedures (SOP) also may require 
that the records division complete an accuracy review for 
compliance to reporting requirements prior to adding the 
information to the database. The system should support all 
required reviews and corrections prior to locking down the 
incident report. 
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investigat 


e Case 


Managemen 


Incidents that require further investigation or follow-up 
may be referred to an investigator before they are closed 
or submitted to the prosecutor for a charging decision. 
Depending on the department’s size and policies, the 
assignment may be made to a patrol officer, generally 

the officer who responded to the original incident, or the 
department's investigative unit. The system should be able 
to assign case responsibility and task responsibility. 


The assigned officer receives these referrals or cases 
electronically and records all of the subsequent case 
management-related activities in RMS. Case management 
functions include, but are not limited to, capturing and 
storing investigation data, requesting a warrant, conducting 
interviews and photo lineups, and producing supplemental 
reports. Investigators also may initiate criminal charges 
and obtain and execute both search and arrest warrants. 
The department should be able to define its specific 
activities, including a time allocation for each activity, 

so the system can generate alerts to both the assigned 
investigator and the supervisor. 


Key products of the process are producing information for 
the prosecutor, assisting in managing case materials (i.e., 
including evidence), and preparing cases for prosecution. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 
® Cases not assigned for investigation or follow-up 
® Case summary 


® Case aging report (list of cases by age range, days, 
weeks, month, etc.) 


© Assigned cases (open cases by investigator and 
current status) 


® Cases pending assignment 


© Activity follow-up 


© Alerts (e.g., overdue, case assignment, and task 
assignment) 

® Pending activity (e.g., by investigator, case, and 
division) 

® Case disposition (both law enforcement dispositions 
and court dispositions) 

® Prosecutor charging documents 


Standard External Data Exchanges: 
© Prosecutor (case submission) 
® Court (disposition exchanges) 


® Regional Information Sharing Systems® (RISS) (i-e., 
standards-based, such as Global JXDM, NCIC) 


® Jail Management System (JMS) 


Standard Internal Data Exchanges: 
® Incident reporting 

® Property and evidence 

© Warrant 


Other Optional External Data Exchanges: 
® Financial management system 


5.1 Use Case Diagram (see page 14) 


5.2 Use Case: Assign Investigator 


The supervisor must be able to access and review 
unassigned cases. The supervisor will assign case 
responsibility to a primary investigator. Assignment factors 
may include the nature of the activity, type of follow-up 
required, the workload of available investigators, and 
cases already assigned. 
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Figure 5.1 Use 
Case Diagram— 
Investigative 
Case 
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5.3 Use Case: Case Monitoring Each activity during this process may result in an update of 
. . : : the status of the investigation. 

Supervisors monitor cases to ensure that progress is being 

made. The information used in case monitoring includes During the course of the investigation, the primary 

case status and activities, both pending and overdue, and investigator may assign tasks to others. The system 

investigator case workload. should be capable of monitoring and tracking at both the 


: : . ‘ case and task levels. 
Supervisors must be able to obtain workload information, 


assess all requests for new investigations, receive Several of the activities that are a part of conducting 
deadlines and reminders, and interact with investigators an investigation are detailed in other sections of 
electronically. They must be able to view existing this document. Investigators may need to create a 
assignments, shift resources, and notify investigators of supplemental report as defined in the Incident Reporting 
changes, as required. module. Warrants may be requested as defined in the 


Warrant module. Evidence collection and disposition is 
P : defined in the Property and Evidence and Management 
5.4 Use Case: Conduct Investigation module. The arrest process is detailed in the Arrest 


Conducting an investigation involves following up on module. 
leads and documenting additional facts about the case. 


The activities associated with the investigation typically ‘ 
include collecting evidence, developing leads, conducting 5.5 Use Case: Charging 


interviews and interrogations, requesting warrants, and In the situation where charges are to be filed, investigators 
writing supplemental reports. Each of these activities must and supervisors must assemble all relevant case 

be documented in RMS to confirm that proper department information and reports, as well as their charging 
procedure was followed and that all potential leads were recommendations, for submission to the prosecutor. 
developed. This documentation may include case notes. The system should support the development of charging 
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recommendations and their electronic approval prior 5.6 Use Case: Case Disposition 
to the submission to the prosecutor. In some cases, When th . ida elewEnt tC 
the prosecutor may refer the case back for further SiLane Ceae ts COlpiee: a Law SNipiceient ess 


: sigs Disposition is captured. This disposition is in addition to 
invesugation. a case status. At this point, any property may be eligible 
The prosecutor may decide to prosecute some, all, ornone _ for release to the owner as defined in the Property and 
of the charges recommended by the law enforcement Evidence Management module. 

agency or decide to prosecute other charges. The 
prosecutor’s charging decisions should be communicated 
to the law enforcement agency, and the system should 
capture the charging decisions. 


A court disposition (per person arrested and per charge) 
also should be included in the record as the court case 
is completed. With an integrated justice system, the 
disposition can be exchanged electronically. The system 
In integrated justice systems, much of the communication should support the ability to reopen a case, if necessary, 
between the prosecutor and the law enforcement agency based on new evidence. 

happens electronically. If no interface is available, the data 

must be entered manually into RMS. 
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Property refers to any tangible item that can be owned, 
consumed, or otherwise used (e.g., stolen or recovered 
items, currency, narcotics, vehicles, animals, and 
evidence of any form) that is to be tracked by the agency. 
Property owned for use by the agency (e.g., department 
equipment) is typically not included in this module. Law 
enforcement agencies can take custody of property during 
the investigation of cases and preserve it for possible use 
at trial. Agencies also will receive property turned over 

by the public in which ownership is unknown or where 
circumstances of receiving the property are unknown or 
unrelated to an event or incident. 


A property custodian is responsible for receiving property 
for the agency. Information about the property, including its 
source, is collected and recorded in RMS. 


Law enforcement personnel can access property data 

to view detailed information about the item and historical 
information about the custody and control of the item, 
including the current status or location. Personnel also can 
follow links to related property items tracked in the system. 
The tracking system provides the ability to accurately 
track and verify that all property items and the evidentiary 
chain-of-custody requirements are met. The system also 
will track property that has been impounded or stored in 
remote facilities. Information about property and evidence 
must be linked to either a case file or a report that 
describes the property’s involvement. 


The disposition of property is managed by the system, with 
timed events to notify property custodians when property 
items will be released, destroyed, or sold at auction. The 
disposition history is maintained for a specified time period 
or may be indexed for future investigative purposes. 


While many RMS include integrated Property and 
Evidence Management modules, many jurisdictions 
are using stand-alone programs to support the property 


and evidence function. Any stand-alone program should 
include an interface to RMS to minimize duplicate data 
entry. Links to appropriate RMS records should be made at 
the time the property record is uploaded. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 

Chain of custody 

Property summary report 
Property item detail 
Released property report 
Property inventory report 
Property disposition reports 


Form letter to inform the property owner of the pending 
disposition of property with instructions for filing a 
claim 


Vehicle impound forfeiture report 
Case closed evidence report 
Evidence location summary report 
Audit report 


Standard External Data Exchanges: 


® Regional Information Sharing Systems (RISS) (i-e., 
based on standards, such as Global JXDM, NCIC) 


® State information sharing systems (i.e., based on 
standards, such as Global JXDM, NCIC) 


©® Prosecutor 
® Court 


Standard Internal Data Exchanges: 
® Incident reporting 
© Fleet management 
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Other Optional External Data Exchanges: 
©  Bar-code system 


® Third-party property management systems, including a 
laboratory evidence processing system 


® Pawn shops 
6.1 Use Case Diagram 


6.2 Use Case: Collect Property and 
Evidence 


Property and evidence items are collected and processed 
into a physical location with established process and 
security controls. This is the point of entry into the system 
where descriptors and tracking identifiers (e.g., date/time 
received, contributing and receiving officers, and location) 


Figure 6.1 Use Case 
Diagram—Property 
and Evidence 
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are recorded for both inventory control and chain-of- 
custody purposes. The property will be checked against 
internal and external databases for matches. RMS will link 
property/evidence information with the case and reports. 


6.3 Use Case: Vehicle Impound 


The law enforcement agency will impound vehicles in 

the normal course of operations. Vehicles might include 
boats, cars, motorcycles, airplanes, and other items used 
for transportation. The system should support the entry 
of all identifying information for all of these vehicle types. 
A vehicle may be impounded as evidence in an ongoing 
investigation or because the driver was driving under the 
influence. A vehicle may be impounded because it has 
been abandoned or because it was parked in a prohibited 
location. 
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The officer who initiates the impound records the reason 
behind the impoundment and information about the towed 
vehicle, including the VIN, description, license number, 
and the condition of the vehicle, as well as information 
about the car owner and driver. 


The vehicle should first be checked against the MVI in 
RMS and then automatically queried in both the state and 
federal repositories for wants and warrants. 


The officer enters his estimate of when the vehicle will be 
available for release and includes the name of the tow 
company that will be moving the vehicle to the impound 
lot. A mobile computing system enables the information to 
be captured at the scene and made available at the time 
the vehicle arrives at the impound lot. 


At the impound facility, the owner and driver information, 
as well as the vehicle identification and description 
information, are validated or updated, and the specific 
location within the facility is added to the record. 
Information related to the tow-and-impound process also 
is captured. An initial estimate of the vehicle’s value may 
be entered. A general inventory is conducted to document 
items that may potentially be removed from the vehicle, 
including personal items, spare tires, gas caps, batteries, 
weapons, etc. This module should support a quick and 
easy way to capture that information. 


If the vehicle has evidentiary value, it will be subject to 

the rules for chain of custody and should be protected 

and tracked by the system like other tangible evidence. 
RMS can treat the vehicle and most of its contents as one 
piece of evidence. However, if additional evidence is found 
during the impoundment process, it can be processed as a 
stand-alone piece of evidence. 


6.4 Use Case: Property and Evidence 
Storage 


Movement of property and evidence, regardless of how 
minor, is recorded to ensure that an accurate log of the 
activity is captured and all policies and chain-of-custody 
rules are followed. Bar-coding the property and using 
RMS during the check-in, checkout, and movement of the 
property will improve the accuracy of the chain-of-custody 
information in the system. 


6.5 Use Case: Property and Evidence 
Disposition 

Final disposition of property is essential to maintaining 
manageable storage capacities for the agency and making 
certain owners have their property returned in a timely 
fashion. The disposition process documents the disposition 
action and includes safeguards to ensure that procedures 
and laws governing the release, sale, or destruction of 

the item are followed. The system will use timed events 

by using system messages or providing access to lists 

of eligible property items to notify the property custodian 
when property can be lawfully disposed. 


The prosecutor’s approval will be required before the 
disposition of property with evidentiary value can go 
forward. The system should provide a means to store 
images of the item prior to the disposition. The system 
may include an interface or exchange capability with the 
prosecutor that affords officials an efficient and accurate 
means by which to review and grant or deny approval of 
disposition requests sent by the law enforcement agency. 


Appropriate identification is required to verify the identity 
of the individual coming to claim a piece of property, 

and a search of information sources may be conducted 
where warranted. For example, if a person comes in to 
claim a weapon, a check of records should be conducted 
to ensure he or she can lawfully possess a weapon. An 
additional check against property databases (e.g., NCIC) 
should be conducted to determine if the property has been 
reported as being stolen. RMS should automate these 
queries and document that they were completed prior to 
the release of property. 


After a prescribed period of time, property is eligible for 
sale or destruction. Only lawful property can be returned 
to the owner or sold at public sale. Any property deemed 
illegal for an individual to possess will be properly 
destroyed. 


The system should generate automatic alerts when 
property is eligible for release or sale. 
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A warrant is an order of a court that directs a law 
enforcement officer to take specific action. For example, 
an arrest warrant would direct a law enforcement officer to 
arrest a person and bring that person before the court. A 
warrant may be issued for a person charged with a crime, 
a person convicted of a crime who failed to appear for 
sentencing, a person owing a fine, or a person that the 
judge has ruled to be in contempt of court. 


The Warrant module is designed to track warrants that the 
law enforcement agency will be serving and that include 
the physical location of the warrant. It also tracks and 
records any warrant-related activity or status changes. The 
documentation of each activity includes the type of activity, 
contact with the subject (if any), the date of the activity, 
and the result of the activity. 


In many departments, other papers (e.g., criminal 
summons) are handled using the process identified in the 
Warrant module. 


The Warrant module should be able to create a warrant 
affidavit requesting that the court issue a warrant. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 
Warrants issued 


Warrants served or cancelled 

Warrant summary based on varying search criteria 
Attempts to serve by date or date range 

Warrant aging report 


Warrant affidavit 


Standard External Data Exchanges: 
® Court 


® Regional, state, and federal warrant repositories 
following NCIC standards 

® Jail Management System (JMS) 

® Corrections 


Standard Internal Data Exchanges: 
® Booking 


® Master Name Index (MNI) 
® Master Vehicle Index (MVI) 
© Master Property Index (MPI) 


7.1 Use Case Diagram (see page 22) 


7.2 Use Case: Receive and Process 
Warrant 


Upon receipt of a warrant from the court, the warrant 

clerk enters the information into the Warrant module. An 
interface with the court system will reduce data entry. Entry 
into the local warrant system will update the appropriate 
regional or state warrant system. The warrant clerk 
reviews the warrant for completeness and ensures the 
subject information is up to date. 


7.3 Use Case: Verify Warrant 


Immediately prior to warrant service, the officer must verify 
that the warrant is still valid before the actual service takes 
place. This is especially important in serving an arrest 
warrant. The warrant verification process is important in 
determining whether the agency is willing to extradite the 
subject if the warrant is served. 
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If available, the verification can be done using a mobile contact with the subject (if any), the date of the activity, 


data computer that has the appropriate interface. As an and the result of the activity. Once the warrant is served, 
alternative, the officer can contact dispatch or another the module is updated and the warrant is cancelled in 
department facility to have the warrant verified. other appropriate warrant systems. 

7.4 Use Case: Warrant Service 7.5 Use Case: Cancel Warrant 

The process for warrant service will depend on the type The court has the ability to cancel the warrant. The reason 
of warrant. The Warrant module tracks and records for the cancellation must be recorded in the Warrant 

any warrant-related activity or status changes. The module. Other appropriate warrant systems also must be 


documentation of each activity includes the type of activity, updated to reflect that the warrant has been cancelled. 


Figure 7.1 Use 
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Arrest 


Law enforcement agencies arrest subjects suspected 

of having committed a crime. Arrest actions must be 
supported by either probable cause rules or definitions 

or a court warrant commanding the arrest of a subject. It 
is essential that the arresting officer follow well-defined 
procedures that include accurately documenting and 
recording every step in the arrest process. Both scenarios 
follow the same procedure when the person is arrested. 


The Arrest module provides a place to document all of the 
steps taken in an arrest. This complete documentation 
may be used to defend the legality of an arrest. 


The data from this report can then be used by the Booking 
module, the Jail Management System (JMS), and the 
court. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 

® Daily arrests, by day and time, and date range 
© Arrest report and/or affidavit 

© Arrests by location 

© Arrest log 


Standard External Data Exchanges: 
© Jail Management System (JMS) 


® Court 
© Prosecutor 
® State criminal history system 


Standard Internal Data Exchanges: 
® Mobile field reporting 

® Incident reporting 

® Booking 


Master Name Index (MNI) 
Master Vehicle Index (MVI) 
Master Property Index (MPI) 
Property and evidence 


8.1 Use Case Diagram (see page 24) 


8.2 Use Case: Arrest Subject 


When a law enforcement officer has control of a subject 
suspected of a crime, the officer will take the subject into 
custody if the circumstances support keeping control of the 
individual to maintain public safety and peace. The officer 
may be making a probable cause arrest, serving an arrest 
warrant, or making a driving-under-the-influence (DUI) 
arrest. 


A probable cause or on-view arrest is based on immediate 
circumstances of an incident, where sufficient evidence 
supports the actions of the law enforcement officer. 
Examples include traffic violations and incidents when 

the officer witnesses the commission of a crime. In some 
cases, the arrest may trigger the detention process and 
booking. 


The law enforcement officer must make every reasonable 
effort to confirm the identity of a subject prior to the 
person’s being taken into custody. The Arrest module must 
allow the officer to capture the method of identification that 
was used. It also must capture the completion of other 
steps such as the issuing of the Miranda warning. 


RMS must provide the capability to print the arrest report 
after all of the data have been entered into the system. 


An arrest report will be required when the law enforcement 
officer takes the final step in the arrest process of 


EEE 
Standard Functional Specifications for Law Enforcement Records Management Systems (RMS) 23 


transporting the person to jail. RMS should facilitate and 
document the agency’s arrest report review process. 


An interface with the appropriate booking and/or Jail 
Management System is desirable. 


8.3 Use Case: Arrest Warrant Service 


There are two situations that may trigger an arrest based 
on the serving of a warrant. The law enforcement officer 
may be serving an arrest warrant that was issued as a 
result of an ongoing investigation. Certain charges will 
have been approved by the prosecutor prior to the warrant 
being issued. These charges may or may not be updated 
prior to the service of the warrant. The arrest now follows 
the same process as a probable cause arrest. 


The second trigger of a warrant arrest is when a law 
enforcement officer conducts a warrant check during a 
traffic stop or some other activity and finds that there is an 
active warrant on file for the person involved. 


Prior to the warrant service, the officer must verify that 

the warrant is still valid. If the warrant was issued by 
another jurisdiction, the law enforcement officer must first 
confirm that the issuing agency is willing to extradite. This 
warrant verification process can be done using a mobile 
data computer that has the appropriate interface. Some 
agencies do not require an arrest report to be written if the 
warrant was issued by another jurisdiction. 


Figure 8.1 
Use Case 
Diagram— 
Arrest 
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After the warrant has been served, it is necessary to 
remove the warrant from all of the appropriate warrant 
systems. 


8.4 Use Case: DUI Arrest 


Driving under the influence of drugs or alcohol or while 
impaired in some other way is considered one of the most 
serious issues for traffic enforcement. Additional steps are 
required prior to the beginning of a DUI arrest. 


This process may be initiated as part of a traffic stop or 
in response to an accident. If the law enforcement officer 
suspects that the driver was using drugs or alcohol, a 
chemical test will be conducted either in the field or under 
more stringent controls. The law enforcement officer 

will ask the subject if he or she is willing to submit to a 
chemical test. The response should be captured in RMS. 
When fatalities are involved, the law enforcement officer 
may be required to obtain chemical tests without the 
consent of the subject. All relevant information regarding 
the results from tests are gathered and recorded to 
supplement the report in RMS. 


Based on the test results, the department’s SOP for 
handling DUI arrests will be followed, and each step will be 
documented in RMS. 


Evidence may be obtained from these types of traffic 
incidents, which require property handling and tracking. 
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Boog 


Booking data captured in a law enforcement RMS are 
eventually linked to the arrest report. The data to be 
captured include personal information of the subject. 


The personal identification information provided by the 
subject will be checked against MNI to create a link to this 
booking and avoid unnecessary or redundant data entry. 
Personal information will include the subject’s name and 
any known aliases; a physical description, including tattoos 
and other identifying marks; address and other contact 
information; date of birth; and identification data, such as 
a driver’s license number or social security number. The 
subject’s fingerprints will be taken as part of the booking 
process. A photo image also will be taken of the subject 
and may include images of any identifying attributes, such 
as tattoos and scars. RMS will provide the capability to 
store the images in the database linked to the booking 
record. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 

Booking form 

Booking summary, based on varying search criteria 
Daily court list by court and time 

Property received receipt 

Property released receipt 


Booking activity (e.g., intakes, releases, and transfers) 


Standard External Data Exchanges: 
® Jail Management System (JMS) 


© Arrest 


® Regional and state warrant and criminal history 
repositories, following NCIC standards 


® Automated fingerprint identification system 
® Mug-shot system 


Standard Internal Data Exchanges: 
©® Master Name Index (MNI) 


© Master Vehicle Index (MVI) 
® Master Property Index (MPI) 
® Property and evidence 


9.1 Use Case Diagram (see page 26) 


9.2 Use Case: Process Subject 


The booking process includes collecting all relevant 
information on the subject and his or her arrest details, 
verifying the subject’s identity, and addressing obvious 
physical and mental health needs. 


This information may be obtained from the arrest report 
record within RMS. If the arrest report is available in RMS, 
a link should be established between the arrest report and 
the booking record. 


If the booking record precedes the arrest record, the data 
from the booking record should prepopulate the arrest 
record. MNI acts as the primary key between the arrest 
record and the booking record. 


Information about the arrest of the subject will be entered 
into the Booking module. 


Agency officials perform an assessment during the 
course of the arrest and booking process. Generally, the 
assessment may follow a checklist of questions in RMS 
to capture noted medical needs and security risks. In 

an integrated environment, this information should be 
forwarded to appropriate external systems including the 
Jail Management System (JMS). 


Property in the possession of the subject will be 
inventoried and stored in a secured area while the subject 
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is in custody. If it is determined that the property will not 
be released to the subject at the time of his or her release, 
then the property should be handled following department 
procedures for property and evidence management. If the 
subject is in custody, agency officials should perform an 
assessment of the subject during the course of the arrest 
and booking process. Generally, the assessment follows a 
checklist of questions and captures in RMS noting medical 
needs and security risks. In an integrated environment, this 
information should be forwarded to appropriate external 
systems, including JMS. 


The subject will be assigned to an appropriate facility and 
bed, based on gender, assessment needs, and space 
availability. Temporary holding areas may be used in cases 
where long-term accommodations are unavailable or 
where the subject’s assessment warrants the assignment, 
such as when medical needs exist or intoxication is a 
factor. 


9.3 Use Case: Verify Subject 


Personal information obtained from the subject will 

be used to obtain verification information from one or 
more sources to affirm or disaffirm the subject’s identity. 
The personal information obtained from or about the 


Figure 9.1 
Use Case 
Diagram— 
Booking 


conducts 
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subject will exist in many forms, including descriptive 

text, fingerprints, DNA, and photographic images. In 

most instances, the verification process will affirm or 
disaffirm the subject’s identity electronically, but in some 
instances, a visual comparison will be necessary to make 
a determination. Fingerprints may be sent to an Automated 
Fingerprint Identification System (AFIS) and the Federal 
Bureau of Investigation’s (FBI) Integrated Automated 
Fingerprint Identification System (IAFIS). 


The system should check MNI plus state, regional, 

and federal databases for any information. The State 
Identification Number (SID), FBI number, and any other 
information returned from AFIS/IAFIS will be added to the 
report as they are received. 


9.4 Use Case: Release 


When a subject is released from custody, bond money 

will be collected, if required, and a check will be made to 
determine if the subject has any active warrants. Prior to 
release, subjects will have their personal property returned 
to them. The booking record will be updated, where 
applicable, to record all relevant information supporting the 
release of the subject from custody, including the reason, 
effective date, and time of release. 


<<includes>> 
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The juvenile justice system requires special handling 

of information about juveniles. Paramount in this is the 
handling of their records, which must conform to legal 
requirements that specifically define privacy protections. 


RMS must accommodate the need to access juvenile data 
distinctly from adult information. 


As with all cases, information about juveniles disseminated 
externally also requires information entered into the 
system to be expunged when ordered by the court or 
statute. Access must be restricted to authorized law 
enforcement personnel with special privileges. 


In some jurisdictions, the juvenile court is actively involved 
in juvenile intake and assessment activities. As such, there 
may be an interface between courts and RMS. Juvenile 
RMS modules also may provide notifications to external 
agencies, such as social services organizations and 
schools, based on certain activities involving juveniles. 


RMS should have the ability to automatically archive 
juvenile information after a requisite amount of time (as 
governed by state law) has passed since the entry or when 
the subject reaches the age of 18 (whichever occurs first). 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 
® Juvenile custody 


® Juvenile contact report 


® Name listing for juveniles separate from adults, based 
on varying search criteria 


Standard External Data Exchanges: 
® Prosecutor 


® Juvenile assessment center 


® Juvenile detention center 
® Jail Management System (JMS) 


Standard Internal Data Exchanges: 
® Mobile reporting system 


Other Optional External Data Exchanges: 
® Social services 


® Court 
® Schools 


10.1 Use Case Diagram (see page 28) 


10.2 Use Case: Juvenile Contact 


A contact with a juvenile should be documented in 

RMS. The contact may result in a citation, referral, or 
detention. Taking the juvenile into custody allows the law 
enforcement officer to have the juvenile assessed and 
ensure the juvenile is not in danger. The law enforcement 
officer will gather information from the juvenile about the 
event to determine whether an offense (or status offense) 
occurred and whether to sanction the juvenile in any way. 


In some jurisdictions, the law enforcement officer who 
takes the juvenile into custody will take the subject to a 
juvenile intake center for assessment. In other cases, 
qualified personnel at the law enforcement agency will 
make the assessment. Once the law enforcement officer 
has determined that the circumstances warrant more than 
admonishment, he or she will determine the appropriate 
recourse or referral. This evaluation is based on the 
nature of the incident, whether weapons were involved or 
narcotics were present, and the number of past contacts 
with the law and victims. In many jurisdictions, referral to 
juvenile intake is mandated if the juvenile has a pattern of 
delinquency over a period of time defined by law. 
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Figure 10.1 
Use Case 

Diagram— 
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The juvenile may be released to a parent or guardian, a 
hospital, or other nonjudicial authority. Informal diversion 
might include requiring the juvenile to perform specific 
community service. RMS has a mechanism that allows 
for timed alert notices if follow-up contact or information is 
necessary. 


RMS will support these activities by documenting the 
contact with the youth in a juvenile contact record. 

It also will guide the law enforcement officer to the 
appropriate remedy, sanction, or referral, depending on the 
circumstances. 


In handling a juvenile contact, law enforcement officers 
must communicate with both the professionals conducting 
the assessment and the juvenile’s parents or guardian. 
RMS must document these communications, as well as 
other information about the juvenile. The youth’s full name, 
age, address, contact (i.e., family) information, physical 
description, gender, and name of school he or she attends, 
as well as information about the incident, are examples of 
information that will be entered into RMS. 


<<extends>> 


Juvenile 
Contact* 


<<extends>> 


Juvenile 
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RMS should have the ability to automatically archive 
juvenile contacts after a requisite period of time (as 
governed by state law) has passed since the entry or when 
the subject turns 18 years of age (whichever occurs first). 


10.3 Use Case: Juvenile Detention 


The juvenile is placed into the care of a custodial facility. 
The system must send appropriate notification to the 
court, the prosecutor, and all appropriate social services 
agencies involved. 


10.4 Use Case: Juvenile Referral 


Formal charges may be brought against the juvenile. 

The juvenile may be released to a parent or guardian, a 
hospital, or other nonjudicial authority. Informal diversion 
may include assigning required community services. RMS 
has a mechanism that allows for timed alert notices if 
follow-up contact or information is necessary. 
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Traffic accident reporting involves the documentation 

of facts surrounding an accident. Typically, these are 
incidents that involve one or more motor vehicles but 
also may include pedestrians, cyclists, animals, or other 
objects. Traffic accident reporting also may be referred to 
by the terms “collision” or “crash.” 


Most states require law enforcement to provide uniform 
documentation and reporting on all traffic and highway 
accidents. The information compiled in accident reports is 
used by the public, insurance companies, traffic analysts, 
and prosecutors to assist in prosecuting individuals where 
a criminal offense also may be included. The accident data 
can also facilitate analysis by identifying necessary road 
improvements and the elimination of traffic safety hazards. 


Typically, Traffic Accident Reporting is a module within the 
agency RMS. The information is typically captured at the 
location of the incident; transcribed into electronic forms 
(e.g., in the field or office); transferred to and used by RMS 
for local analysis; and, in many jurisdictions, transmitted to 
the state transportation department. In some jurisdictions, 
traffic accident reporting is performed using a separate 
software system, which often is provided by the state 
transportation agency. 


The module also should allow the officer to collect data 
on the demographics of the people involved, to collect 
statistics for reporting on bias-based policing evaluations. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 
® State accident report 


® Accidents by location 
® Accidents by time of day and day of week 
® Accidents by violation 


Accidents by severity 
Accidents by driver demographic 
Statistical summary by intersection 


Statistics by area (e.g., beat, precinct), day, and time 


Standard External Data Exchanges: 
® State motor vehicle division 


® Local, regional, and state transportation departments, 
using U.S. Department of Transportation (DOT) 
standards 


© Traffic engineering using DOT standards 
® Community development 
Standard Internal Data Exchanges: 


Property and evidence 


® Mobile reporting system 

® Citation 

® Master Name Index (MNI) 

® Master Vehicle Index (MVI) 
© Master Property Index (MPI) 
© Arrest 

® Citation 

@ 

e 


Fleet management 
11.1 Use Case Diagram (see page 30) 


11.2 Use Case: Accident Reporting 


Traffic accident reporting requirements differ from 

general criminal incident reports in that they emphasize 
the cause of the accident; weather, visibility, and road 
surface conditions at the time of the accident; and location 
information. Therefore, traffic accident reporting systems 
usually include drawing or diagramming tools to assist 
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Figure 11.1 
Use Case 
Diagram— 
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in accurately capturing accident scene and location 
information. 


The system should support the ability to attach accident 
diagrams and photographs to the accident report. If a 
citation is issued as a result of the accident, the citation 
should be linked to the accident report. 
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Individuals or organizations charged with minor offenses 
often are issued a citation or ticket, which requires them to 
pay a fine, post a bail amount, and/or appear in court on a 
specified date. Citations are commonly used in traffic and 
misdemeanor law enforcement. 


The offender is given a copy of the citation that may 
contain a preassigned court appearance date. When 

the citation data are entered or uploaded into RMS, the 
appropriate links should be made to the master index 
records. The court clerk is notified of the charges, either 
by receiving a paper copy of the citation or an electronic 
copy of the citation data. Often, the offender can pay a fine 
or forfeit a bail amount to satisfy the fine. In the event that 
the court date is not assigned when the citation is issued, 
itis assigned at a later date. The Citation module should 
capture the court data and record the court’s disposition of 
the citation. 


In many jurisdictions, a uniform citation form is used by all 
law enforcement agencies. The application that supports 
the creation of the citation may be a module of RMS or a 
third-party solution designed for the creation of citations in 
the field. 


If the subject is not issued a citation from a citation book, 
the application must be able to print the citation. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 


® Citation and warnings summary based on varying 
search criteria 


® Citation by location 
® Citations and warnings by demographic data 
® Citation audit (e.g., missing/voided numbers) 


Standard External Data Exchanges: 
® Court 


Jail Management System (JMS) 


Prosecutor 


e 
© Warrant 
@ 
© Department of Motor Vehicles (DMV) 


Standard Internal Data Exchanges: 
Mobile reporting system 


Traffic accident reporting 

Incident reporting (e.g., misdemeanor citations) 
Master Name Index (MNI) 

Master Vehicle Index (MVI) 

Master Property Index (MPI) 

Arrest 


Juvenile contact 
12.1 Use Case Diagram (see page 32) 


12.2 Use Case: Issue Citation 


Citation information is stored and tracked in RMS. 
Officers will enter information about a violation or charge, 
as well as relevant court information, into RMS. The 
citation information will then be sent to the court, either 
electronically, if the appropriate interface is in place, or 
manually. 


The officer issuing the citation needs to query state 

and local databases that contain information regarding 
previously issued citations and warnings. The query also 
should check for any outstanding warrants or alerts. 


A law enforcement officer may decide to issue a warning 
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Figure 12.1 
Use Case 
Diagram— 
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instead of a citation. RMS must track warnings, as well as The module also should allow the law enforcement officer 

citations. Both must be linked to the subject’s master name to collect data on the demographics of the people involved, 

record. to collect statistics for reporting on bias-based policing 
evaluations. 
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A field contact record is created by a law enforcement 
officer based on the department’s SOP. Typically, 

this process is triggered by unusual or suspicious 
circumstances or any activity that is considered by the 
law enforcement officer to be of interest but would not 
otherwise be documented in RMS (see the Incident 
Reporting module for more details). The data in the Field 
Contact module are available for analytical support (crime 
analysis). It also can be searched by investigators to 
develop leads. 


Field contacts are not subject to the same stringent review 
and approval process as incident reports. 


The module also should allow the officer to collect data on 
the demographics of the people involved in order to collect 
statistics for reporting on bias-based policing evaluations. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 


® Field contact summary, based on varying search 
criteria 


Standard External Data Exchanges: 
® State repositories, NCIC 


® Mug shots 
® Fingerprints 


Standard Internal Data Exchanges: 
® Mobile reporting system 

® Master Name Index (MNI) 

© Master Property Index (MPI) 

© Master Vehicle Index (MVI) 


13.1 Use Case Diagram (see page 34) 


13.2 Use Case: Document Field Contact 


A field contact is documented, usually at the discretion 
of the law enforcement officer, based on an observation 
or information indicating suspicious or unusual activity or 
circumstances, such as the following: 


© Aparked car in an area and at a time normally vacant 
of cars 


® One or more people in an area and at a time normally 
vacant of people 


® One or more people loitering in a vulnerable area 


® People and vehicles that appear to be out of place for 
any particular reason 


Specific areas may be targeted for field contact based on 
departmental policy. Such targeting may be for high-crime 
areas or in potentially sensitive areas, such as areas near 
schools and religious institutions. 


The information collected includes: 


® Location and time 

® General circumstances 

® Names and descriptions of persons 

® Identifying information on vehicles or other property 


Field contact information serves as a key input to analytical 
support (crime analysis) and other investigative processes. 
It helps to establish links between persons, vehicles, and 
crime events. Because of this, field contact information 
should be consistent with data standards used in the 
analytical support/crime analysis process. 


Field contact reports, unlike incident reports, are normally 
not subject to a stringent supervisor review and approval 
process. They are, however, reviewed to ensure the 
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Figure 13.1 
Use Case 
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quality and adequacy of reporting and consistency with 
departmental policy and statute. 
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Pawn modules in RMS help law enforcement 
representatives identify and recover personal property 
that has been reported stolen. Many jurisdictions require 
pawnshops to register the items they receive and sell to 
facilitate this tracking process. 


Specific functionality of the Pawn module includes: 


® Collecting, storing, and tracking pawn data 
® Comparing pawn data with lost or stolen property 


® Supporting the investigative process for matches or 
patterns 


® Running inquiries to external regional, state, and 
federal systems 


® Providing data necessary to serve the needs of state 
pawn systems 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 


® Pawn summary based on varying search criteria (e.g., 
date, time of sale, and property type) 


® Frequent pawner list 


Standard External Data Exchanges: 
® State and regional pawn systems following NCIC 
property standards 


® Local pawnshop computer systems following NCIC 
property standards 


Standard Internal Data Exchanges: 
® License and permits 

® Master Property Index 

© Property and evidence 


14.1 Use Case Diagram (see page 36) 


14.2 Use Case: Receive and Process 
Pawn Data 


The pawn shop must submit pawn tickets to the law 
enforcement agency—either by paper or electronically. 
This information is then entered into the Pawn module. 
In the event the property record has a unique identifier, 
such as a serial number, inquiries may be made to local 
and external systems. In addition, the name of the person 
pawning the item and personal identity documentation 
information (e.g., driver’s license number) should be 
included. Depending on the type of property being 
pawned, name inquiries may be made to state and 
national systems. 


As new items are added to the stolen property database, 
the pawn database should be automatically queried to 
determine if the item was previously reported as being 
pawned. 


Any positive hits that return from these external inquiries 
require follow-up on the part of the pawn unit. This follow- 
up could include seizing property or further investigation. 


14.3 Use Case: Seize Pawn Property 


When the pawn unit has identified pawned property that 
was reported stolen, the pawn record is updated to reflect 
that the article had been reported stolen and then seized. 
The pawn unit will take action to seize the property for 
evidentiary or safekeeping purposes. The property is then 
checked into the Property and Evidence Management 
module and, at this point, becomes part of an investigation. 
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Figure 14.] 
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14.4 Use Case: Analysis of Pawn Data 


The Pawn module will analyze pawn data versus stolen 
data to identify trends and patterns. Examples of analysis 
include frequent pawn activity by location, person, type, 
etc. The module must create reports to support the 
analysis. 


14.5 Use Case: Regional and State Pawn 
Reporting 
If an external repository maintains pawn data, information 


from local Pawn modules may be transmitted to these 
systems electronically. 
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Civil process describes the law enforcement agency 
responsibility to serve legal papers and execute legal 
processes as required to facilitate due process through the 
judicial system. These functions are commonly performed 
by sheriffs’ offices, which are entitled to payment by private 
parties for such service. RMS modules should allow the 
data entry of papers to be served, as well as the capability 
to track the service of civil papers. There often is a data 
exchange with a billing or accounting system. 


The agency may be required by statute to serve these 
court documents as prescribed and within specified time 
limits. These documents may include writs, summons, 
subpoenas, warrants, judgment orders, and civil 

protection orders. RMS will provide the ability to record the 
disposition of all actions required by the order, including 
court-ordered eviction, the seizure of property, and 
collection of court-ordered fees. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 
® Active civil papers (e.g., by age, jurisdiction, and 
server) 


Served/returned civil papers 
Civil paper/civil paper jacket 
Expired civil papers 

Notice generation 

Letter generation 

General financial 


Civil summary (e.g., paper summary, assignments, 
and attempts to serve) 


Affidavit of service 


Standard External Data Exchanges: 
® Accounting system 

® Court 

® Jail Management System (JMS) 


Standard Internal Data Exchanges: 
Master Name Index 


Master Vehicle Index 

Master Location Index (MLI) 
Master Property Index (MPI) 
Master Organization Index (MOI) 


Warrant 
15.1 Use Case Diagram (see page 38) 


15.2 Use Case: Serve Orders 


The service of orders to individuals, organizations, or other 
justice officials is based on court orders or subpoenas. 
Service of orders also includes evictions. There will be 

a good faith effort to serve the order as many times as 
necessary up to the expiration date. The service attempts 
and circumstances will be documented. The system 
generates an affidavit of service to the court on successful 
service or expiration of the order. 


15.3 Use Case: Seized Property 


Seized property describes the process and action 

of seizing personal property, based on a court order 
presented to a law enforcement officer. The individual or 
organization is served the order to voluntarily relinquish the 
property. On failure to relinquish property on a designated 
date, a property seizure will be scheduled and executed. 
All service attempts, as well as the order execution, will be 
documented in RMS. 
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Figure 15.1 
Use Case 
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15.4 Use Case: Billing 


An agency’s RMS should collect the information pertaining 
to any fees associated with an order service and transfer 
billing data to the financial system for billing, collection, 
and distribution of funds. Billing information includes whom 
and when to invoice, billing amounts, and the allocation 
and disbursement of fees. 
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Law enforcement agencies receive court orders for Standard External Data Exchanges: 
protection directly from the court or the protected party. ® CAD 

This module is used to record protection orders and ® Cou 

restraints, including antiharassment orders, protection ae 

orders, no-contact orders, and civil protection orders. All ® National Protection Order Registry (NPOR) 
parties named in the orders and their relationship to the © Jail Management System (JMS) 

order must be stored in the system. The conditions of the 

order are stored as well. The conditions should include Standard Internal Data Exchanges: 
information such as the issuing authority, effective time © Master Name Index (MNI) 

period, location, distance, restrictions, and type of contact 
prohibited. This information must be readily available by 
name and location of the parties and also may be cross- 
referenced by vehicle. 


Master Location Index (MLI) 
Master Vehicle Index (MVI) 
Master Organization Index (MOI) 
Master Property Index (MPI) 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


16.1 Use Case Diagram (see page 40) 
Standard Outputs: 


Expired/soon-to-expire orders 


16.2 Use Case: Protection Order and 
Restraint Recording 
A valid protection order or restraint is recorded in RMS. 


Active orders 

Orders that have been served 
Orders received, by source 
Cancelled orders 


No trespass order 
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Figure 16.1 
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The Permits and License module records and tracks the 
issuance of licenses by agency. Examples of devices and 
activities that require a license include, but are not limited 
to, electronic alarms, firearm ownership, and operating 
massage parlors. Examples of permits include parade, 
race, or demonstration permits. Licensing is generally for 
an extended period of time, while permits provide authority 
for a shorter and specific period of time. 


The status of licenses and permits is tracked, including 
application granting, denial, revocation, and expiration. 
The change of status or an upcoming expiration date 
generates appropriate alerts and notifications. 


Applicant names are checked against the system MNI. 
Depending on the type of license or permit, there may 
be criminal history or other background information that 
precludes the applicant’s eligibility to obtain the license. 


Once a license is issued, if the licensee is arrested or is 
issued a traffic violation, the system will generate an alert 
to notify the permit and license group to determine whether 
the license should be revoked. 


The system also must track the payments associated with 
the issuance of licenses and permits or link with a financial 
system to determine payment status. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 


® Permits and license applications granted based on 
varying search criteria 


© Permits and license applications denied with reason 
® False alarm responses, for billing purposes 
® Expiration notice 


Standard External Data Exchanges: 
® CAD (e.g., call data from alarms) 


Other Optional External Data Exchanges: 
© Financial management system 


17.1 Use Case Diagram (see page 42) 


17.2 Use Case: Application Processing 


The application process includes reviewing the application 
to ensure all requirements are met. The review will result in 
either an approval or denial. The decision will be recorded 
in the RMS, and a notification will be generated by the 
system and sent to the applicant. 


Guidelines for approval may include successful completion 
of specific training and/or passing a background check to 
verify the absence of relevant criminal history. There may 
be fees associated with the application process. 


17.3 Use Case: Collection 


The system will either receive notification of payment 
receipt from the financial system or record payment for the 
application. This module merely associates the payment 
with the application; it does not include cash drawer 
accounting. 


17.4 Use Case: Background Investigation 


The purpose of the background investigation is to 
determine whether the individual is eligible for the license 
or permit. The type of permit or license may require 
differing investigative steps and procedures, such as 
collecting fingerprints and criminal history checks. 
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17.5. Use Case: Suspension-Revocation 
Once the license has been issued, if a licensee is arrested 
or has traffic violations, the system will generate an alert to 
notify the permit and license group to determine whether 
the license should be revoked. 


The above situation can result in the generation of a 
notification letter to the licensee. 
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Equipment management describes the processes that the 
law enforcement agency uses to: 


® Record the receipt of equipment 
® Record the source of the equipment 


® Issue equipment to an organizational element or 
individual 
® Track equipment check-in or checkout 


Management and tracking of equipment may be facilitated 
by the integration of bar-coding equipment, a Radio 
Frequency Identification Device (RFID), etc. The system 
should have the ability to store photographs of the 
equipment. 


The Equipment and Asset Management module should 
generate reports to support the physical inventory and 
audits, which will assist in managing the repair, disposal, 
and maintenance of agency equipment. 


In some agencies, inventory and control of agency 
property are regulated by authorities outside the law 
enforcement agency. If this is regulated by an outside 
agency, an interface between the two systems may 
minimize duplicate data entry. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 


© Physical inventory report, based on varying search 
criteria (e.g., category, age, unit, and location) 


® Physical inventory exception report 
®  Check-in/checkout log 
® Equipment history 


External Data Exchanges: 


® Regulating authority (e.g., general services, facility 
services) 


Other Optional External Exchanges: 
® Financial management system 


® Purchasing 
18.1 Use Case Diagram (see page 44) 


18.2 Use Case: Equipment Receipt 


The Equipment and Asset Management module will allow 
the capture of descriptive characteristics of the equipment, 
associated identifiers on the equipment, and any agency- 
specific unique identifier, such as an inventory control 
number. 


18.3 Use Case: Equipment Issuance 


Equipment may be assigned to an organizational element 
(e.g., unit, division, or group) of the agency, a physical 
location, or an individual. In addition, equipment may be 
assigned on a check-in/checkout basis (e.g., daily basis, 
for patrol). The system must maintain a log of all activity. 


Equipment may be authorized but not issued (e.g., a 
personally owned weapon). The authorization to carry that 
equipment must be captured. 


18.4 Use Case: Equipment Checkout 


When equipment is checked out to a unit or authorized 
person, information about the checkout (e.g., individual 
receiving equipment, date and time of equipment 
checkout, and condition of equipment) is recorded for 
tracking purposes. 
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This process may be facilitated by the use of bar-code or 
RFID equipment. 


18.5 Use Case: Equipment Check-in 


The return of equipment will include an evaluation of 
the condition of the item, performance of maintenance 
procedures, disposition of equipment deemed unfit for 
service, and the return of functional equipment. 


The system must support the generation of reports for 
overdue, lost, stolen, or destroyed equipment. 


18.6 Use Case: Physical Inventory/Audit 


This function of the system must be able to generate 
reports about the physical whereabouts of agency 
equipment. The physical inventory will result in the 
identification of missing equipment, as well as equipment 
recommended for repair, replacement, or disposal. This 
process may identify that the location of the equipment 


Figure 18.1 Use 
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has changed. All information gathered during the physical 
inventory is used to update the system. 


18.7 Use Case: Equipment Maintenance 


The system shall record information about equipment 
condition and maintenance. The information recorded 

in this module includes reason for repair, cost of repair, 
date of repair, maintenance location, date expected back 
in service, date returned to service, and date of next 
scheduled maintenance. 


18.8 Use Case: Equipment Disposal 


This is the process associated with taking a piece of 
equipment out of service and disposing of it. The system 
changes the equipment status but will not delete or remove 
historical records associated with that item. 


issued 


<<includes>> 
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Fleet management includes all vehicle types (e.g., 
car, motorcycle, boat, and aircraft) and generally 
encompasses: 


® Tracking and issuance of fleet assets 


® Tracking service and maintenance schedules and 
history 


© Parts inventory and warranties 
® Fuel and oil inventory and usage 
® Vehicle disposal 


When maintenance or repair work is performed by a 
contractor, the fleet management module may include 


functions to track vendors and the services they provide. 


Equipment assigned to vehicles may be associated 
with the identifiers issued by the Equipment and Asset 
Management module. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 

Fleet inventory 
Maintenance schedule 
Fleet repair log 

Fluid consumption/cost 
Vehicle repair cost 


Fleet equipment list 


External Data Exchanges: 
® CAD (e.g., for mileage and use information) 


Other Optional External Data Exchanges: 


© External fleet management system managed by city, 
county, or agency 


® Fuel card system 


19.1 Use Case Diagram (see page 46) 


19.2 Use Case: Fleet Receipt 


The Fleet module will allow the capture of: 


© Descriptive characteristics of the vehicle (e.g., color, 
make, and model) 


Date the vehicle was deployed 
Starting mileage 
Identifiers (e.g., VIN and license plate number) 


Any agency-specific unique identifier 


This module also will establish the service schedule, such 
as tune-ups and oil changes. 


19.3 Use Case: Fleet Issuance 


Fleet issuance refers to tracking events related to fleet 
asset issuance and where fleet is assigned. Vehicles 

are assigned to a particular organizational element or 
individual. The system should allow the ability to track the 
issuance history of the vehicle. 


19.4 Use Case: Fuel Log 


The Fleet module records the date, price, and amount 
of fuel purchased at each fill-up, as well as the vehicle’s 
mileage at the time of fill-up. This assists the agency in 
tracking fuel-related costs. 


If the agency uses a fuel card system, there may be an 
interface between it and the Fleet module to import the fill- 
up data directly. 
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19.5 Use Case: Fleet Maintenance 19.6 Use Case: Damage Reporting 


The system can be used to record information about Agency personnel and the fleet manager will periodically 
vehicle maintenance and service. The information assess the condition of the vehicle and record any 
recorded in this module includes: damage. 
® Projected and actual maintenance schedule This may or may not lead to a repair or maintenance 
© Fluid servicing activity. It also may lead to an assessment of officer 
re, : performance. 
® Vendor providing service 
® Repair schedule 
© Repair and maintenance costs 19.7 Use Case: Fleet Disposal 


This process is associated with taking a vehicle out of 
service and disposing of it. The system changes the 
vehicle status but will not delete or remove historical 
records associated with that item. 


In addition to periodic scheduled maintenance, a vehicle 
can enter this process if it is determined to be in need of 
unexpected repair. 


Figure 19.1 
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The Personnel module allows law enforcement managers 
to capture and maintain information on the individuals 

in their department, including volunteers. It also may 
include information on people outside the department 
who have received training from the department (e.g., 
people attending a citizen’s academy). This information 
typically includes the person’s basic information, such 

as emergency contacts, current and past assignments, 
education, training history, and certifications. 


In most locations, information about the employee also 
is maintained in an external human resource system. 
To avoid duplicate data entry, an interface should be 
established between the personnel system and the law 
enforcement RMS personnel module. 


This module addresses those functions that are unique to 
a law enforcement agency and/or are typically not found in 
a stand-alone human resources software program. 


The Health Insurance Portability and Privacy Act (HIPPA) 
applies to those agencies that provide health care. 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 
Personnel summary, based on varying search criteria 


Personnel detail 

Duty roster 

Training and certification scheduling 

Pending certification and skill expiration 

Issued equipment based on varying search criteria 


Health maintenance requirements for duty status 


Standard External Data Exchanges: 
® Human resources 


© Staffing deployment system 
® CAD 


Standard Internal Data Exchanges: 
® Equipment and asset management 


© Fleet management 
20.1 Use Case Diagram (see page 49) 


20.2 Use Case: Operational 
Management 


RMS should be able to draw on RMS data to identify 
potential personnel and organizational issues. The 
information includes biased-based policing, uses of force, 
vehicle pursuits, vehicle crashes, employee injuries, 
citation data, field contact reports, citizen complaints, and 
civil and criminal actions. 


Management should be able to conduct analyses, as well 
as ad hoc reporting on these parameters. Management 
should have the ability to define thresholds on data 
elements of interest and be notified when certain values, 
either above or below the thresholds, have been reached. 


20.3 Use Case: Personnel Information 


The system must allow for the gathering and maintenance 
of basic information for all personnel working for 

the department. Information may include names 

and addresses, physical characteristics, assigned 
equipment, emergency contact information, special skills, 
classifications (e.g. sworn/nonsworn), and rank histories. 
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Health maintenance is important to agency productivity, 
and some aspects of protecting employee health are 
mandated by law. The Personnel module will support 
tracking required vaccinations and medical baselines, 
such as titer tests for tuberculosis exposure. An agency- 
specific table should maintain information on vaccinations 
required by law or recommended by the agency and each 
vaccination’s duration of efficacy. The Personnel module 
will collect information on date, type, and expiration date 
of vaccinations employees receive. Reports generated to 
supervisors will alert the agency to upcoming expirations 
and needed vaccinations. Similarly, the module will collect 
information on current health-related duty restrictions 
affecting employees, produce supervisor reports to ensure 
employee duties are assigned appropriately to prevent 
injury, and permit longitudinal tracking and analysis of 
medical limitations for risk management. 


20.4 Use Case: Scheduling and 
Assignment 


The scheduling portion allows for the creation and 
maintenance of schedule patterns (e.g., days on, days 

off, and assigned hours). The assignment portion records 
the officer assignment, shift, and location and associates 
the officer with a particular pattern. As assignments 
change, the personnel record is updated to reflect the new 
assignment. All exceptions to the officer assignment must 
be recorded. 


The system creates the duty roster, which is based on the 
assignment, schedule, and exceptions to the schedule. To 
be able to generate past and future rosters, a complete 
history of assignments, patterns, and exceptions are 
maintained. 


If the department uses a manpower deployment system, 
the system can be used for defining and finalizing changes 
in the overall plan for resource utilization, and changes 

in the assignment can be updated in the Personnel 
Information module. These automated updates will require 
an interface between the two systems. 


20.5 Use Case: Exceptions 


After schedules and assignments have been generated, 
it will then be necessary to document all conflicts with 
previously created work schedules. The exception 

can include any other duty or assignment outside the 
scheduled or assigned pattern (e.g., training; vacation or 
sick leave). 


20.6 Use Case: Duty Roster 


From the scheduling rotation, assignment, and exception 
information, the system generates the duty roster for a 
particular time period (e.g., past, present, or future) the 
supervisor selects. 


20.7 Use Case: Training and 
Certification 


The Personnel module tracks training history and the 
certification process. The certification process includes 
officer certification status; deadlines for maintaining 
certifications, including necessary hours of training, etc.; 
and student performance. 
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A law enforcement agency’s Internal Affairs (IA) Division 21.2 Use Case: Conduct IA Investigation 
thoroughly investigates allegations of misconduct on the 


part of employees of the department The purpose of an IA investigation is to ensure that 


department policy and procedures are followed and that 
There are several common administrative requirements agency standards of professionalism are adhered to by all 
that help isolate the IA investigation information. The department employees. 

IA system must have multiple levels of security for the 
application itself, for individual records or groups of 
records, and for individual or groups of fields. Due to the 
sensitivity of the information collected in IA functions, the 
data could be encrypted. 


In many ways, IA investigations are conducted in a manner 
similar to criminal investigations. Subjects, witnesses, and 
complainants are interviewed and that information, along 
with the facts of the case, is recorded in the Internal Affairs 
module. 


RMS will store all information related to the IA 
investigation. 


Security levels within the Internal Affairs module will limit 
the availability of information accessible through other 
RMS modules and indices. An agency-designated recipient 
will receive an alert whenever a party to an investigation is 
the subject of a query or if any other RMS activity occurs 
regarding that party. 


21.1 Use Case Diagram 


Figure 21.1 
Use Case 
Diagram— 
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Analytical support is the systematic process of collecting, 
collating, analyzing, and disseminating timely, accurate, 
and useful information that describes patterns, trends, 
problems, and potential suspects. RMS should support the 
tools used by the analyst in this work. Analytical support 
can be subdivided into four main types: 


). Tactical Analysis: Provides information to assist 
operations personnel in the identification of specific 
policing problems and the arrest of criminal offenders. 


2. Strategic Analysis: Provides information concerning 
long-range crime problems. Strategic crime analysis 
provides information concerning crime rate variations 
and provides geographic, economic, social, and/or 
other types of general information to administrators. 


3. Administrative Analysis: Provides information to 
support administrative decisions related to resource 
allocation and to support budget requests and 
decisions. 


4. Forecasting Analysis: A combination of tactical, 
strategic, and administrative analysis; merging multiple 
sets of data. 


In addition to being able to query and produce ad hoc 
reports on any number of indicators, analytical support 
also includes standardized reporting functionality. One 
example of a standardized report is crime statistics. Crime 
statistics are essentially comparative statistics on the 
community crime rate, which can be disaggregated by 
specified timeframes, offenses, and complaints by beat or 
zone. 


RMS must interface with analytical support tools, such as 
crime-mapping software and link-analysis, data mining, 
spatial, and temporal tools. The results of these analyses 
should be stored in RMS for a time determined by the 
jurisdiction's SOP and can be used to assess agency 
performance and provide support for administrative 


decisions. RMS should have a variety of reporting 
functions attached to their Analytical Support modules and 
allow presentation of information in a variety of formats, 
such as bar graphs, pie charts, and line graphs. 


RMS should support the ability to aggregate data on the 
various indicators, such as: 


® Current period vs. previous period 
® Current period vs. historical average 
© Percentage of total crimes for period by: 
® Reporting districts 
® Areas/beats/zones 
®  Teams/shifts 
© Percentage change from prior periods (i.e., trend) 


RMS should contain the ability to conduct crime 
distribution analysis based on a number of criteria, 
including: 

By area/beat or reporting district (i.e., ZIP codes) 
By time, date, and day of week 

Frequency of occurrence 

Citation 

Crime/incident report number 

Field interview data 

Search warrant data 

Vehicle information 


Type of offense (e.g., residential, auto, or business) 


The system also should include standardized reports, such 
as general offense activity, offense activity by day of week, 
and offense activity by beat. Every field of operational 

data in RMS (i.e., data entered by the user in any form, 
not configuration or system control data) should be 
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searchable, including narrative (e.g., text or memo) fields. 
This can be done by using query interfaces that are part 
of the application or, at a minimum, using third-party tools 
that can access the operational database via Open Data 
Base Connectivity (ODBC). 


RMS should include an alert function related to analytical 
support to provide for the immediate transmission of 
information to law enforcement officers in the field. 


RMS should support a quality control process on incoming 
reports to ensure that data are correctly and completely 
entered. 


RMS should contain complete data elements that relate 
to time, such as the day, time of day, week, date, month, 
and year. It also should include a locally determined and 
previously validated geographic reference. 


RMS should support crime/suspect correlations to 

show a relationship between a suspect and an offense. 
The correlations may be made by using any number 

of selected criteria in which unique and distinguishing 
characteristics, physical identifiers, modus operandi, and 
various other common traits of offenders are known. These 
identifiers may be captured as a part of multiple different 
business functions, including incident, field contact, arrest, 
accident, citation, MNI, MVI, MLI, and MOI. 


Standard Output: 


® Crime distribution analysis reports using the criteria 
listed above 


Standard External Data Exchanges: 

® Third-party mapping and graphing tools 

® Regional Information Sharing Systems (RISS) (i-e., 
based on Global JXDM, NCIC standards) 


22.1 Use Case Diagram (see page 55) 


22.2 Use Case: Tactical Analysis 


Tactical analysis provides information to assist personnel 
in the identification of specific, immediate crime or 
disorder problems and the arrest of criminal offenders. 
Tactical analysis provides information to assist personnel 
(e.g., patrol and investigative officers) in preventing 

and disrupting criminal behavior, identifying specific 


and immediate crime problems, and arresting criminal 
offenders. Analytical data are used to promote a quick 
response to field situations. 


22.3 Use Case: Strategic Analysis 


The purpose of strategic analysis is to provide information 
concerning long-range problems. Strategic analysis is 
primarily concerned with solutions to ongoing problems. 

It results in the ability to accomplish the agency mission 
more effectively and efficiently. 


22.4 Use Case: Forecasting Analysis 


The purpose of forecasting analysis is to prevent crime 

by analyzing information collected in RMS and correlating 
it with external sources. It can involve the application of 
advanced analytical methods to forecast the occurrence of 
specific crimes or trends. 


RMS should support the ability of the analyst to generate 
the Forecasting Analysis report. The report’s format should 
be tailored to meet the particular requirements of the 
customers who receive the information, whether they are 
patrol, investigative, or administrative personnel. 


22.5 Use Case: Administrative Analysis 


Administrative analysis develops long-range (e.g., 
quarterly, semiannually, or annually), strategic 
comparisons and reports them externally. Examples of 
administrative crime analysis tasks may include providing 
economic, geographic, and law enforcement information 
to law enforcement management, neighborhood/citizen 
groups, other appropriate agencies, and the public. 


Where required by the agency’s SOP, RMS should 
support the ability to generate statistical reports on all law 
enforcement activities within that agency, allocate costs 
to those activities, and track performance measures as 
defined by the agency. 
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RMS reports document officer and agency-wide activity or 
performance in a given area. Many reports are created 
over the course of conducting policing business (e.g., 
arrest report and incident report). Aggregated reports are 
conducted by line and supervisory staff and reviewed by 
law enforcement executives. Role-based security should 
restrict access to some reports. 


Law enforcement personnel must be able to generate 
standardized reports and aggregate reports, as well as 
query RMS to produce ad hoc reports from the RMS 
reports module. 


Examples of standardized reports from RMS business 
functions are: 


Incident reports 
Accident/crash reports 
Property/evidence reports 


Field interview reports 


Uniform Crime Reports (UCR)/National Incident-Based 
Reporting System (NIBRS) 


® Case management reports 


e 
e 
e 
® Citation reports 
e 
e 


© Billing reports 


® Summary reports for warrants, citations, CFS, 
accidents, and employees 


Typically, third-party products are used for ad hoc queries 
and reports. 


23.1 Use Case Diagram (see page 58) 


23.2 Use Case: Aggregate Reporting 


Aggregate, agency-wide reporting allows law enforcement 
personnel to associate information in a variety of ways 
and among a number of different tables or fields, including 
CFS, warrants, incident reports, traffic data, property data, 
and weapons data. 


Managers must be able to query, retrieve, and display 
information in a variety of ways. They must be able to 
query on indicators, such as date of the incident, case 
type, and assigned officer. They should be able to produce 
reports from a list of standardized reports or on an ad hoc 
basis. 


The query and data retrieval system must be integrated 
with the RMS security system so that the department can 
designate search and query types and depths by password 
or groups of passwords. 


23.3 Use Case: Standardized Reporting 


Each module includes its own set of standardized reports, 
which also are available through the RMS Incident 
Reporting module. 


23.4 Use Case: Ad Hoc Reporting 


The agency may need operational reports and analysis 
that are not provided by standard RMS reports and 
queries. Ad hoc reporting will allow a user to define and 
create these additional custom reports. Once created, 
these custom reports can be saved and run as standard 
reports. 


RMS should provide a tool that can be used to produce 
any number of ad hoc reports. 
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These ad hoc reporting tools may be provided using a However, there are trade-offs, such as the security issue 


third-party solution. This solution may be imbedded in noted above. 

the application or run as a stand-alone. Ad hoc reporting 

functions that are imbedded into the RMS solution may Another approach is to extract data, excluding secured 

use existing RMS security controls. Stand-alone, information, into separate data warehouses. That way, 

ad hoc applications open the potential to bypass the RMS stand-alone, ad hoc tools could be used to access the data 
security controls (e.g., juvenile data, sealed records, and without compromising RMS security controls. 


redacted records). The stand-alone approach may allow 
an agency to have a broader selection of ad hoc tools. 
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While most RMS systems are standard, they should be 
configurable so that they can be used to meet specific 
agency requirements. The RMS systems administration 
functions address RMS configurable aspects. 


System administration encompasses a wide array of 
general functions that law enforcement agencies need 
from their RMS to be able to create and query information 
effectively; ensure appropriate access to information 

and systems security; and ensure effective departmental 
information, image, and document management. 


Examples of administrative functions include: 


RMS table maintenance 

RMS configurations (e.g., parameters, defaults) 
Security (e.g., user role, jurisdiction) 

Geofile 


Data management (e.g., data dictionary, archive and 
purge) 


Standard Outputs, External Data Exchanges, and 
Internal Data Exchanges 


Standard Outputs: 


® Report on users, sortable by names, access level, 
password age, and machine used 


® Report on RMS use, sortable by user log-in, frequency, 
total time in system, number of concurrent log-ins, 
machine used, and duration time-outs 


® Report on failed log-ins, sortable by log-in name, 
number of attempts, date/time of attempt, and machine 
used 

® Report on subsystem security violations 


® Alerts; user-definable security violations, which 
generate an external message to predefined locations 


Standard Internal Data Exchanges: 
® Agency network operating system 
© E-mail system for alerts 


24.1 Use Case Diagram (see page 60) 


24.2 Use Case: Security 


Systems should allow tiered access to information, based 
on passwords and other authentication and nonrepudiation 
practices. Role-based authentication and authorization 
must be a part of RMS. Other identification technologies 
such as biometrics, identification cards, and security 
tokens are emerging standards. 


Systems should apply appropriate edits to all entered data 
to ensure data integrity and maintain activity logs and audit 
trails. 


24.3 Use Case: RMS Table Maintenance 


RMS should include the ability for the user agency to 
define and maintain codes and associated literals (i-e., 
plain English translation) for as many data elements as 
possible. The literals should be stored in the database, as 
appropriate. 


Where available and applicable, RMS should use the 
authoritative code tables referenced in Global JXDM and 
NCIC. 
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24.4 Use Case: Data Management the department. The type of information that is edited 
includes victims’ names in certain types of cases, juvenile 


information, or information that is considered by the 
agency to be sensitive to an investigation. 


Data management includes the following: 


® Record expungement and sealing 


® Data redaction In the case of formatted and structured data, report output 
© Data dictionary programs can produce a redacted version of specific report 
data. In the case of narrative or otherwise unstructured 
information, the redaction process requires a manual step 
to produce a public version of the report. 


These topics are further described in the following 
paragraphs. 


Record Disposition 

RMS must be able to support expungement, sealing, and 
purging of whole records and partial records. To support 
this function, the system must be able to flag a record, 
flag data elements within a record, and delete a record. Data Dictionary 
The flag should indicate why the record or data element is 
restricted. 


Generalized report tools, if employed to produce reports 
for public consumption, should be used only on data that 
have already been redacted. 


RMS must provide a capability to display and/or print the 
database structures to allow the end user to access the 
database tables through third-party, ad hoc inquiry tools/ 


Data Redaction iat 
utilities. 


Redaction is the process of editing report information 
to filter sensitive or confidential information before the 
report is released to the public or for general use outside 
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The data dictionary may contain the following information 
for each field description: 


Field name (e.g., external representation) 

Database column name (e.g., internal representation) 
Data type (e.g., numeric, alpha, or date) 

Field size 

Field format (i.e., output format) 

Edit or validation criteria 

Associated code table 

Default value 


Description 


24.5 Use Case: Geofile Maintenance 


The geofile is used to validate and standardize location 
and address information. It also is used to cross-reference 
addresses and locations with law enforcement-defined 
reporting areas, X/Y/Z coordinates, ZIP codes, and other 
identifiers. The geofile contains sufficient information to 
ensure that an address is valid. Furthermore, it provides 
cross-references to addresses and locations using 
commonplace names (e.g., business names, parks, 
hospitals, and schools) and street aliases. It includes 
information such as direction of travel on particular streets 
and can identify the side of a street for a specific address. 
It is assumed that all addresses in RMS are validated 
using the system geofile. 


The reporting area defined above should be used to 
define beats, sectors, command areas, neighborhoods, 
communities, etc. 


The geofile contains the geographic information that is the 
basis for many decisions in a communications center. The 
system needs to provide the ability for an agency to enter 
and update all geofile data, including the physical address 
and the X/Y/Z coordinates. 


The creation of a comprehensive geofile is a significant 
undertaking. The system should support the creation and 
maintenance of the geofile using an available mapping/ 
Geographic Information System (GIS) database. Geofile 
information in CAD and RMS should be synchronized, 
based on established parameters. 


24.6 Use Case: RMS Configuration 


Some parameters of RMS should be configurable by 
the system administrator. For example, the system 
administrator should be able to modify the system 
variables, such as agency and chief’s name, Originating 
Agency Identifier (ORI), address, and phone number. 
Changes to parameters, such as juvenile default age, 
X/Y/Z or state plane geography coordinates, and name 
match rules, should be allowed. 


The system administrator also must have the ability to 
define the conditions under which an alert or notification is 
issued. 


In a multijurisdictional RMS, the system administrator 
should be able to change the parameters for each 
participating agency. 


Any configuration changes that could affect system 
integrity must be properly flagged with adequate warning 
to prevent inadvertent damage to the system. 
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RMS frequently requires functionality to exchange data 
with other systems. The exact nature of those exchanges 
will, in large part, be determined by local business 
practices and local agency work flows. All interfaces need 
to comply with national standards. Each business function 
includes examples of data exchanges. 


25.1 Use Case Diagram 


25.2 Use Case: CAD Interfaces 


Information may be transferred from CAD to RMS when 
units are initially dispatched, an incident number is 
assigned, and/or the call is closed in CAD. 


CAD users require the ability to retrieve information from 
RMS based on name, location, and vehicle descriptors. 
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25.3 Use Case: Local/Regional Interfaces 


RMS users need to access and possibly update a variety 
of local and regional systems. Examples include courts, 
prosecutor, financial systems, Jail Management Systems, 
human resources systems, and multijurisdictional 
information systems. Data exchanges with many of these 
systems are identified in the specific business functions in 
this specification. 


These interfaces should be based on national standards, 
such as Global JXDM and NCIC. 


25.4 Use Case: State/Federal Interfaces 


RMS needs to query, add, or modify information stored in 
state and federal systems. Examples include updates for 
wanted people, missing people, stolen vehicles/property, 
and state sex offender registries. 


These interfaces should be based on national standards, 
such as Global JXDM and NCIC. 


[ n terfaces 
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LEITSC had a mission to create a national standard for 
law enforcement RMS and has succeeded in carrying out 
this task. 


The RMS functional standards are meant to describe 

the minimal amount of functionality that an RMS for law 
enforcement should contain. These standards should be 
used as a Starting point to build a fully functional RMS, 
based on agency needs and open standards, to efficiently 
interface and share information with other systems, both 
internally and externally. They are designed to serve as a 
guiding tool for law enforcement agencies and should be 
tailored to fit the specific needs of each law enforcement 
agency or group of agencies looking to upgrade or 


purchase a new RMS. Although the RMS functional 
standards were not developed to substitute for an RFP, 
they can be used to supplement an RFP. 


The functional standards found in this document are 
intended to be generic in nature and do not favor one 
particular system or approach over another. They are at 
the functional level, meaning that they define what is to be 
accomplished versus how it should be accomplished. 


The RMS functional standards were developed by the 
LEITSC Functional Standards Committee and are now 
available to all law enforcement agencies. 
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Automated Finger Print Identification System 
Bureau of Justice Assistance 

Computer Aided Dispatch 

Calls for Service 

Department of Motor Vehicles 

U.S. Department of Justice 

U.S. Department of Transportation 

Driving Under the Influence 

Electronic Fingerprint Transmission Specification 
Federal Bureau of Investigation 

Geographic Information System 

Global Justice XML Data Model 

Health Insurance Portability and Privacy Act 
Internal Affairs 

International Association of Chiefs of Police 
Integrated Automated Fingerprint Identification System 
Integrated Justice Information System Institute 
Jail Management System 

Law Enforcement Information Technology Standards Council 
Mobile Data Computer 

Master Location Index 

Master Name Index 

Master Organization Index 

Master Property Index 

Master Vehicle Index 


National Crime Information Center 
National Incident-Based Reporting System 
NIEM National Information Exchange Model 
NIJ National Institute of Justice 
NIST National Institute of Science and Technology 
NOBLE National Organization of Black Law Enforcement Executives 
NPOR National Protection Order Registry 
NSA National Sheriffs’ Association 
ODBC Open Database Connectivity 
OJP Office of Justice Programs 
ORI Originating Agency Identifier 
PERF Police Executive Research Forum 
RFID Radio Frequency Identification Device 


Request for Proposal 

Regional Information Sharing Systems 
Records Management Systems 

State Identification Number 


SOP Standard Operating Procedures 
UCR Uniform Crime Report 


VIN Vehicle Identification Number 
‘MI Extensible Markup Language 
Longitude, latitude, and altitude 


